This is the mail archive of the
mailing list for the systemtap project.
function probe oddities
- From: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: <systemtap at sourceware dot org>
- Date: Tue, 11 Jul 2006 14:52:27 -0700
- Subject: function probe oddities
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:
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
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.
Also affected are kretprobes, which may end up registering the kretprobe
instance many times.
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. However, since two aggregate
probes would be faster than taking two consecutive debug traps, it would
be nice if these used the same address.
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...