Re: Inserting profiling function calls

["Michael Gong" <mwgong at cs dot utoronto dot ca>]

----- Original Message ----- 
From: "Frank Ch. Eigler" <fche@redhat.com>
To: "Michael Gong" <mwgong@cs.toronto.edu>
Cc: "GERIN Patrice" <patrice.gerin@imag.fr>; "Jan Hubicka" 
<hubicka@ucw.cz>; <gcc@gcc.gnu.org>
Sent: Saturday, February 10, 2007 10:21 AM
Subject: Re: Inserting profiling function calls


> "Michael Gong" <mwgong@cs.utoronto.ca> writes:
>
> > I don't know about inserting call at the basic block level, but I am
> > quite sure inserting calls at the function level could be done by
> > aspect-oriented-programming (AOP). [...]
>
> Another possibility, coming soon[1], is to use systemtap[2] probes:
>
> % stap -e 'probe process("./a.out").function("*") { log 
> (probefunc()) }'
>
> Among major differences between this approach and AOP are:
>
> - no recompilation of the target program is required: it's more like
>  running a quick background scriptable debugger
> - the instrumentation instead would be inserted into the
>  programs on the fly via breakpoints, probably overall slower
> - we rely on OS kernel facilities for those breakpoints,
>  which means Linux only at this time
> - the instrumentation (log...) language is rubber-padded and safe
> - there can be no interference amongst concurrently running
>  instrumentation packages, or upon the main program: it's 
> non-intrusive

Current AOP approachs, either AspectC or AspectC++, are source-code 
level weaving, ie. they are implemented as a source-to-source 
transformation tool.
1. They can insert functions , called advice, in the locations which can 
be specified by the programmer. So the insertion locations are quite 
flexible. For example, programmer can insert functions only in the 
control flow of some functions.
2. The advice code can access the parameter or the return value of the 
functions, and use or modify them inside advice functions.
3. The inserted codes by AspectC are thread-safe.




> FWIW, yet another technology possibility I know of for this sort of
> data collection is frysk[3].
>
> - FChE
>
> [1] "coming soon" == as soon as those kernel facilities allow
>    ptrace-style breakpoint insertion into user space.  At this time,
>    we can only probe the kernel proper.
> [2] http://sources.redhat.com/systemtap/
> [3] http://sources.redhat.com/frysk/