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
>* 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
Re: On strategies for function call instrumentation
Hi!
I totally agree with Basille. Actually pretty similar thing was
implemented by Liang Peng (ICT) as GCC GSoC'09 project -
http://ctuning.org/wiki/index.php/CTools:ICI:Projects:GSOC09:Function_cloning_and_program_instrumentation
So, probably you should take a look at the code in the
instrumentation part of this project.
On Tue, Nov 24, 2009 at 5:38 PM, Basile STARYNKEVITCH
wrote:
> Mark Mitchell wrote:
>>
>> Derrick Coetzee wrote:
>>
>>> 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.
>
>
> With the next GCC, it can be done inside a plugin. I tend to believe this
> could be a good use case for a plugin, and the plugin infrastructure is
> probably mature for that. You probably could do that in GIMPLE/SSA without
> adding a new port.
>
> Regards.
>
>
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>
Re: On strategies for function call instrumentation
Mark Mitchell wrote:
Derrick Coetzee wrote:
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.
With the next GCC, it can be done inside a plugin. I tend to believe this could be a good use case for a plugin, and the
plugin infrastructure is probably mature for that. You probably could do that in GIMPLE/SSA without adding a new port.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: On strategies for function call instrumentation
Derrick Coetzee wrote:
> 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.
I think you will need to do (2). The source-to-source approach probably
isn't robust enough for what you need to do. You *might* be able to do
it if you pull all calls out of the arguments, but then you have to do
things like:
f(g()) -> temp = g(), f(temp)
before you put in your asm, and if you're in C++ land, you're now
doomed, since creating named temporaries can change the semantics of
programs.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
