Re: function probe oddities

[Roland McGrath <roland at redhat dot com>]

When there is no prologue, there is indeed nothing really to do.  In the
arbitrarily far-off future in the context of arbitrarily vastly more
convenient access to arbitrarily extensive machine features, a trap there
could get the location before last branch from the CPU in magic ways and so
distinguish a call from an iteration.  But short of that, it's hard to see.

Probably more common are situations where there is a little bit of prologue
before the loop.  For those, we could do better by making entry probes
start at the beginning rather than the end of the prologue.  The main
reason we made the translator go to the trouble of finding the end of the
prologue is that originally GCC's DWARF location information for the
parameters was often unreliable at PCs inside the prologue.  We believe
that the latest GCC versions we're now using to build new kernels have
thoroughly fixed that problem.  I even think the RHEL4 version of GCC 3.4
has had enough of the same fixed backported that it doesn't have these
problems.  But that was not the case when we got systemtap entry probes
with target variable access working originally.  

Since there was so much effort put into it back then, I think we have been
understandably loathe to mess with the status quo.  It's the conservative
thing to keep it, especially if there is any desire to widen the set of
compilers for building a kernel that systemtap can work with.  

If you're up for some experimentation, it might be worthwhile to add a
switch to disable the prologue detection.  Then try all the target variable
access you can, and see if it all still works as it did before.

There are reasons other than old GCC bugs that function entry breakpoints
going after prologue code is desireable.  For traditional debugger
breakpoints, that's the point at which stepping will do something
meaningful.  When you want a breakpoint for the purpose of changing some
program state, be it a traditional debugger or a write-capable guru probe,
then before the prologue completes you might not be able to write into
parameter or local variable locations and have your changes affect the
source level variables the way you want them to.  Those concerns are
probably not immediately relevant for systemtap.


Thanks,
Roland