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: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Michel Dagenais <michel dot dagenais at polymtl dot ca>
- 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:12:36 -0400
- Subject: Re: [ltt-dev] Linux Trace terminology - feedback requested
- References: <446CF3B8.8020602@am.sony.com> <1148046542.9362.33.camel@localhost.localdomain>
Hi -
> [...] In source tracepoints could be "statically compiled out"
> (through proper C preprocessor magic) or compiled in as "static
> tracepoints". They may even be statically compiled out but later
> inserted as dynamic tracepoints.
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. There is no PC associated with a piece of code that the
compiler can't see - thus no dynamic breakpoint insertable "there".
> [...] Of course the typical case is "in source tracepoints" used as
> "static tracepoints" and "externally described tracepoints" used as
> "dynamic tracepoints". Nonetheless, it is important to at least
> stress the fact that static tracepoints can be compiled out for zero
> overhead.
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.
- FChE