----- 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/
