This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: On strategies for function call instrumentation


Hi Derrick,

As Yuri pointed out we needed some similar instrumentation
for our function cloning work. It may not be exactly
what you need but could be useful. 

By the way, it seems that you are interested to use GCC as a research 
platform. In this case, sorry for a small advertisement, but I would
like to draw your attention to the GROW'10 workshop which
brings together GCC people using this compiler for research
purposes. The deadline just passed but you may still be interested
to look at the past ones or participate in the future ones. It is 
co-located with the HiPEAC conference and the HiPEAC network
of universities is using GCC as a common research platforms.

We have been developing Interactive Compilation Interface to simplify
the use of GCC for researchers and make research plugins more portable
during compiler evolution. It is a collaborative effort and after GSoC'09 
we are trying to move some of the functionality to the mainline. 
You are warmly welcome to participate in those activities or you can
follow recent discussions at this mailing list:
http://groups.google.com/group/ctuning-discussions

Hope it will be of any use,
Grigori


>    * From: Derrick Coetzee <dc at moonflare dot com>
>    * To: gcc at gcc dot gnu dot org
>    * Date: Mon, 23 Nov 2009 19:44:10 -0800
>    * Subject: On strategies for function call instrumentation
>
> Hi, I'm Derrick Coetzee and I'm a grad student working with Daniel
> Wilkerson et al on the Hard Object project at UC Berkeley (see
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-97.html). To
> minimize implementation effort, we'd like to use gcc as the compiler
> for our platform. The main trick is, to implement our custom stack
> management, we need to inject a custom instruction before each
> function call begins pushing its arguments, and insert a different
> instruction right after each function call. We considered a couple
> different ways to do this:
>
> 1. We have a C/C++ source-to-source translation framework. We could
> translate each function call "f(a,b,c)" to something like "({ _asm {
>... }; typeof(f(a,b,c)) result = f(a,b,c); _asm { ... }; result; })"
> 2. We could modify the code generation of gcc in a private fork.
>
> Our main concern is that we need to be sure the instructions will be
> executed at the right time, right before it starts pushing arguments
> for the function and right after it returns, even in complex contexts
> like nested function calls (f(g(a,b),c)). We're not sure how much gcc
> will reorder these type of sequences, or what optimizations we might
> be neglecting to consider. We're also not sure if we might be
> overlooking superior approaches to the problem. Any advice is
> appreciated.
>
> -- 
> Derrick Coetzee
> University of California, Berkeley



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]