This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

James Dickens


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]