Hi, I am learning dtrace and I find the "fbt:::entry" on sparc platform behaves strange. When I try to run the following script, the results on sparc platform really confused me. The output on sparc is similar to: 1 => open /var/ld/ld.config ...... 1 -> dnlc_lookup 1 -> bcmp 1 -> bcmp 1 -> bcmp ...... 1 -> bcmp 1 -> bcmp 1 -> bcmp 1 <- bcmp 1 <- dnlc_lookup ...... 1 <= open 2>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. I also check the instructions of bcmp return and dnlc_lookup return. They are not call insturctions both. So I think it''s not a tail-call optimization. However, everything is ok on the x86 platform. The script is: #!/usr/sbin/dtrace -Fs syscall::open:entry, syscall::open64:entry { self->spec = speculation(); speculate(self->spec); printf("%s", stringof(copyinstr(arg0))); } fbt::: /self->spec/ { speculate(self->spec); } syscall::open:return, syscall::open64:return /self->spec/ { speculate(self->spec); trace(errno); } syscall::open:return, syscall::open64:return /self->spec && errno != 0/ { commit(self->spec); self->spec = 0; } syscall::open:return, syscall::open64:return /self->spec && errno == 0/ { discard(self->spec); self->spec = 0; }
> >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 -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070906/64dd894a/attachment.html>