----- Original Message ----- From: "Frank Ch. Eigler" <[EMAIL PROTECTED]>
To: "Michael Gong" <[EMAIL PROTECTED]>
Cc: "GERIN Patrice" <[EMAIL PROTECTED]>; "Jan Hubicka" <[EMAIL PROTECTED]>; <gcc@gcc.gnu.org>
Sent: Saturday, February 10, 2007 10:21 AM
Subject: Re: Inserting profiling function calls



"Michael Gong" <[EMAIL PROTECTED]> 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/



Reply via email to