Re: function probe oddities

[Jim Keniston <jkenisto@us.ibm.com>]

On Tue, 2006-07-11 at 14:52, Stone, Joshua I wrote:
> I've recently noticed that it's possible to have function probe that
> don't behave quite like one would expect.  The problem is when you have
> a loop at the very beginning of a function, such that there aren't any
> prior instructions that aren't part of the loop.  You then get a probe
> that fires on every iteration of the loop, instead of only at the
> entrance to the function as desired.
> 
> Consider this trivial example:
> 
> void simple()
> {
>     do
>         work();
>     while (test());
> }
> 
> 00000000 <simple>:
>    0:   e8 0a 00 00 00          call   f <work>
>    5:   e8 06 00 00 00          call   10 <test>
>    a:   85 c0                   test   %eax,%eax
>    c:   75 f2                   jne    0 <simple>
>    e:   c3                      ret
> 

So weird, yet so innocent.  (The problem, not Josh. :-))

> 
> There isn't anywhere that you could place a probe that will only fire at
> the beginning of the function!  This kind of thing is probably a rare
> occurrence, but I have seen it in real code.  I'm not sure that we can
> do anything about it, but this limitation should at least be noted.

Yes, a patch to Documentation/kprobes.txt is warranted.  I'll do it when
I get back from vacation, if nobody beats me to it.

> 
> Also affected are kretprobes, which may end up registering the kretprobe
> instance many times.

Yes, indeed.

> 
> On a related note, I have noticed that function() and function().return
> probes are not always placed at the same address.  I would guess that
> this is because the former needs to be after the prologue, but the
> latter doesn't care about the prologue.

Kretprobes wants kp.addr to be the first instruction of the function, so
it can be sure of where to find the return address (as specified by the
ABI).  There's actually no reason you couldn't specify a later
instruction, so long as the return address is still where kretprobes
looks for it.  That wouldn't help in this case, though.

> However, since two aggregate
> probes would be faster than taking two consecutive debug traps, it would
> be nice if these used the same address.

Nice, but not a big concern.

> My 'real-world' scenario that triggered this investigation had a
> function with a small prologue followed immediately by a loop body.  I
> was trying to trace the call sequence using thread_indent().  I ended up
> with what looked like a whole lot of function entrances with only one
> function exit.  It turns out that the call-probe (post-prologue) was
> firing every time through the loop, but the return-probe (pre-prologue)
> only fired once.
> 
> Given that we may not be able to fix the looping problem, I think I
> would prefer that the return probes carried the same weird behavior.  If
> the return probe used the same address as the call probe, then at least
> I could get a 1:1 mapping between call/return probes...

As previously mentioned, adjusting kretprobes would be problematic.

The gcc folks may come to our rescue, though -- e.g., by helping
SystemTap notice such situations.  Back when SystemTap was having
trouble locating the end of the prologue for some functions, I suggested
training SystemTap in each architecture's ABI, so it could find the args
right at function entry.  The preferred solution, as I recall, was to
enhance the dwarf info.

It's an interesting problem, all right.

> 
> 
> Josh

Jim