This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [ltt-dev] Linux Trace terminology - feedback requested
- From: Michel Dagenais <michel dot dagenais at polymtl dot ca>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Tim Bird <tim dot bird at am dot sony dot com>, systemtap <systemtap at sourceware dot org>, CE Linux Developers List <celinux-dev at tree dot celinuxforum dot org>, ltt-dev <ltt-dev at shafik dot org>, Tohru Nojiri <nojiri at sdl dot hitachi dot co dot jp>
- Date: Fri, 19 May 2006 11:58:35 -0400
- Subject: Re: [ltt-dev] Linux Trace terminology - feedback requested
- References: <446CF3B8.8020602@am.sony.com> <1148046542.9362.33.camel@localhost.localdomain> <20060519151236.GA7883@redhat.com>
> Have you heard of any system that does that effectively? In systemtap
> we've found that it is not unusual for the kernel compiler to mangle
> code and data flows so much that there is little hope for an
> arbitrarily placed *comment* ("compiled out") to be preserved in a
> sensible way.
This is unfortunately very true. Perhaps you can leave a label or a
special directive that effectively reserves that location in the code
and somewhat limits what the optimizer will do there.
> This distinction seems to offer little value. A really compiled-out
> static probe is just as useful as a dynamic-probe script that is not
> running.
...
> If, on the other hand, "compiled-out" means something milder, like
> leaving a number of NOPs in the object code, then we should consider a
> different term, since even NOPs don't come free.
Then indeed we may need a name for these things; do we have something in
the source code, is there something in the binary (NOPS place holder,
conditional instruction...).