Re: R.F.C. Should we abandon User-land probes?

[Richard J Moore <richardj_moore at uk dot ibm dot com>]

systemtap-owner@sources.redhat.com wrote on 20/10/2005 19:15:59:

> Hi
>
> Because of Systemtap's language lack of support for structs, unions,
> typedefs, Systemtap ends up just being a counter, couldn't a userland
> app be written to count the number of times a function is called.
>
> The lack of support for those language construct is bad enough for
> kernel probes, it can be worked around with pre-made tapsets, but are
> we going to write custom tapsets for every app every written?
>
> Guru-mode is no solution, do we have to disable all the work the
> Systemtap coders to make Systemtap as safe as possible. Guru-mode can
> never be used in a production system without lots of testing. In the
> end it would be easier to use other methods, to debug the problem.
> Resorting to Guru-mode makes the system unstable. You end up debugging
> your script, instead of debugging the app.
>
> Further more, the chance of having an app pass a bad pointer increases
> dramatically and may even be the reason they are probing the app in
> the first place.  As we all know passing a bad pointer in a userland
> app, crashes the app, but do the same in the kernel we get an oops, or
> the system crashes. You may even write code to handle such events in
> Systemtap but that isn't used in guru-mode.
>
> The only way I see that Systemtap can be useful with userland probes
> is to implement support for structs, unions and typedefs. It would be
> even more helpful if you implement cpp support, so you can include
> header files into scripts.
>

I disagree entirely.

Whether user-mode probes are useful given the current functionality depends
on the purpose to which they are being put. From the perspective of having
to diagnose some hard-to-reproduce load-realted problem I would find the
current functionality essential. If necessary I would objump -S  the user
code in order to determine what to place my probes and what data to
examine. If it helps me debug an obscure but severe problem then I'll take
whatever help I can get.

Don't throw out the baby with the bathwater.

Richard J Moore (LTC, IBM)

> James Dickens