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