Random ideas about systemtap dependencies

Random ideas about systemtap dependencies

[Tim Bird]

As I've been thinking about the operation of SystemTap
(as I understand it), I got to wondering about something.

Please excuse this long-winded introduction...

I maintain a system called KFT - Kernel Function Trace,
which allows you to monitor the entry and exit of every
kernel function.  It does this by using GCC compiler
flags to put callouts in the prolog and epilog
of every function, at compile time.  KFT can log
all the functions, but in normal usage it filters
by function duration and only shows those functions which
take a long time to execute.  (Finding long-duration
functions is really it's primary purpose, although it
can be used for other things.)  However, KFT can
also filter by function address, allowing you
to only invoke the event handler when certain
specified functions are entered and exited.

Would it be theoretically possible to adapt
SystemTap to use this as a method of monitoring
function entry and exit, rather than using Kprobes?
I ask because I think that some embedded platforms
don't have Kprobe support, but every platform I know
of supports the GCC compiler switches for instrumenting
functions.  Use of this would have lots of drawbacks,
so I'm not recommending it.  I'm just thinking out
loud.  Does SystemTap have any dependencies
on other kernel features that are not available on all
architectures?
(Things like timers are architecture dependent, but
a board will always have at least gettimeofday, though
it may have cruddy resolution).

Anyway, just an idle thought.
 -- Tim


=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================

Re: Random ideas about systemtap dependencies

[Roland McGrath]

A general answer is that systemtap is intended to have many flavors of
probes, with the level of things like kprobes being an implementation
detail used by some probes.  The present prevalence of kprobes in the
implementation of systemtap probes will not necessarily always be the case.

Specifically, are you talking about compiling with -pg?  I can see making
that work with a special-purpose mcount (a little per-machine work there)
that looks up PC locations in a table of probeable spots.  I think the work
required in integrating that with the translator is mainly in getting all
the exact PC locations that mcount will be looking up.  From the kernel
build one needs to glean this static list of potential probe sites, and
then jigger the translator to resolve each "entry" probe to the correct
statically chosen PC for the named function.  With that, the existing
machinery for things like target variable access should do fine working
from the correct PC.  Of course, only function entry probes can be
supported this way.

So in short, it's doable and fits fine into the larger scheme of things.
There is a fair bit of work you'd have to do, but it doesn't inherently
clash with what we're doing.


Thanks,
Roland

Re: Random ideas about systemtap dependencies

[Tim Bird]

Roland McGrath wrote:
> A general answer is that systemtap is intended to have many flavors of
> probes, with the level of things like kprobes being an implementation
> detail used by some probes.  The present prevalence of kprobes in the
> implementation of systemtap probes will not necessarily always be the
> case.
> 
> Specifically, are you talking about compiling with -pg? 

No, KFT uses -finstrument-functions

> So in short, it's doable and fits fine into the larger scheme of things.
> There is a fair bit of work you'd have to do, but it doesn't inherently
> clash with what we're doing.

Thanks for the response.  I'm not sure I'm going to do anything,
but it's interesting to think about.  Especially since I've
been thinking about how different tracing systems can
leverage each other's work.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================

Re: Random ideas about systemtap dependencies

[Roland McGrath]

> No, KFT uses -finstrument-functions

Ah, even better.  That would be straightforward to support in the runtime
for both entry and exit probes.

> Thanks for the response.  I'm not sure I'm going to do anything,
> but it's interesting to think about.  Especially since I've
> been thinking about how different tracing systems can
> leverage each other's work.

We're very much interested in unifying other efforts with systemtap.


Thanks,
Roland