Thanks very much! I see. :)
I also suspect that "bcmp" is a leaf procedure, and the first
instruction is branched back to.
At first, I think I am confused with leaf procedure and tail call maybe.
Best regards,
Jia
-----Original Message-----
From: Adam Leventhal
Sent: 2007?09?06? 06:14
>From the output, "fbt::bcmp:entry" probe is actived for several times,
but "fbt::bcmp:return" only 1 time. So the function entries and returns
are not balanced at all.
This is indeed confusing. If you take a look at how bcmp is compiled on SPARC
you'll notice that it contains a backward branch to the start of the function:
bcmp: brz,pn %o2, +0x2c <bcmp+0x2c>
bcmp+4: sub %o2, 0x1, %o2
bcmp+8: ldsb [%o1], %o5
bcmp+0xc: ldsb [%o0], %o4
bcmp+0x10: add %o0, 0x1, %o0
bcmp+0x14: cmp %o4, %o5
bcmp+0x18: be,pt %icc, -0x18 <bcmp> <===
bcmp+0x1c: add %o1, 0x1, %o1
bcmp+0x20: mov 0x1, %o5
bcmp+0x24: retl
bcmp+0x28: sra %o5, 0x0, %o0
bcmp+0x2c: clr %o5
bcmp+0x30: retl
bcmp+0x34: sra %o5, 0x0, %o0
We always treat the first instruction as the entry to the function. It's
unfortunate that the compiler has laid out the function this way, but there
are a couple of things we could do in DTrace. One is that we could treat
bcmp+0x18 as a conditional return site so that we'd see a corresponding
number of entry and return firings. Another, more complex, option would be
to change the flow of control for this case so that the code at bcmp+0x18
branched to the code in the fbt trampoline to avoid firing the probe.
Feel free to file a bug.
Adam
_______________________________________________
dtrace-discuss mailing list
[email protected]
