vitezslav batrla
2005-Sep-01 13:36 UTC
[dtrace-discuss] pid:::return in frameless function
Hello everybody, Has anyone seen this: here is disassembled function before probe pidXXX::getpassphrase:return was aplied:> getpassphrase::dislibc.so.1`getpassphrase: mov %o7, %g1 libc.so.1`getpassphrase+4: mov 0x100, %o1 libc.so.1`getpassphrase+8: call +8 <libc.so.1`__getpass> libc.so.1`getpassphrase+0xc: mov %g1, %o7 And here it is disassembled after probe pidXXX::getpassphrase:return was aplied: libc.so.1`getpassphrase: mov %o7, %g1 libc.so.1`getpassphrase+4: mov 0x100, %o1 libc.so.1`getpassphrase+8: call +8 <libc.so.1`__getpass> libc.so.1`getpassphrase+0xc: ta 0x38 It look like this function has no frame (or how it is called correctly?) and dtrace puts the return probe in the delay slot resulting in bad return value in arg1. Is it known problem or not ? Btw: I''m running S10GA Have a nice day, Vita
Roch Bourbonnais - Performance Engineering
2005-Sep-01 13:52 UTC
[dtrace-discuss] pid:::return in frameless function
Correct, Dtrace does not set arg1 correctly for return probes that correspond to
tail calls.
iteam: could we just forbid reference to arg1 for return probes that potentially
hit tail calls ?
-r
vitezslav batrla writes:
> Hello everybody,
>
> Has anyone seen this:
>
> here is disassembled function before probe pidXXX::getpassphrase:return
was aplied:
>
> > getpassphrase::dis
> libc.so.1`getpassphrase: mov %o7, %g1
> libc.so.1`getpassphrase+4: mov 0x100, %o1
> libc.so.1`getpassphrase+8: call +8
<libc.so.1`__getpass>
> libc.so.1`getpassphrase+0xc: mov %g1, %o7
>
> And here it is disassembled after probe pidXXX::getpassphrase:return was
aplied:
>
> libc.so.1`getpassphrase: mov %o7, %g1
> libc.so.1`getpassphrase+4: mov 0x100, %o1
> libc.so.1`getpassphrase+8: call +8
<libc.so.1`__getpass>
> libc.so.1`getpassphrase+0xc: ta 0x38
>
> It look like this function has no frame (or how it is called correctly?)
and dtrace puts the return probe in the delay slot resulting in bad return value
in arg1. Is it known problem or not ?
>
> Btw: I''m running S10GA
>
> Have a nice day,
>
> Vita
>
>
>
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
vitezslav batrla
2005-Sep-01 14:31 UTC
[dtrace-discuss] pid:::return in frameless function
Why not forbid return probes in tail calls at all and display an error instead (or don''t match them)? In fact, this probe is executed somewhere between the entry and the return. Or am I wrong? - Vita On Thu, 2005-09-01 at 15:52, Roch Bourbonnais - Performance Engineering wrote:> Correct, Dtrace does not set arg1 correctly for return probes that correspond to > tail calls. > > iteam: could we just forbid reference to arg1 for return probes that potentially > hit tail calls ? > > -r > > > vitezslav batrla writes: > > Hello everybody, > > > > Has anyone seen this: > > > > here is disassembled function before probe pidXXX::getpassphrase:return was aplied: > > > > > getpassphrase::dis > > libc.so.1`getpassphrase: mov %o7, %g1 > > libc.so.1`getpassphrase+4: mov 0x100, %o1 > > libc.so.1`getpassphrase+8: call +8 <libc.so.1`__getpass> > > libc.so.1`getpassphrase+0xc: mov %g1, %o7 > > > > And here it is disassembled after probe pidXXX::getpassphrase:return was aplied: > > > > libc.so.1`getpassphrase: mov %o7, %g1 > > libc.so.1`getpassphrase+4: mov 0x100, %o1 > > libc.so.1`getpassphrase+8: call +8 <libc.so.1`__getpass> > > libc.so.1`getpassphrase+0xc: ta 0x38 > > > > It look like this function has no frame (or how it is called correctly?) and dtrace puts the return probe in the delay slot resulting in bad return value in arg1. Is it known problem or not ? > > > > Btw: I''m running S10GA > > > > Have a nice day, > > > > Vita > > > > > > > > > > _______________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss at opensolaris.org >
vitezslav batrla
2005-Sep-01 14:42 UTC
[dtrace-discuss] pid:::return in frameless function
Thanks, for showing me the term "tail call". Now my life is much better :) Ok, I have found it in the documentation: return Probes A return probes fires when the traced function returns or makes a tail call to another function. The value for arg0 is the offset in the function of the return instruction; arg1 holds the return value. IMHO there should be that arg1 holds "some" value in the case of the tail call, depending on the function code. It could be easily e.g. an input argument. - Vita On Thu, 2005-09-01 at 15:52, Roch Bourbonnais - Performance Engineering wrote:> Correct, Dtrace does not set arg1 correctly for return probes that correspond to > tail calls. > > iteam: could we just forbid reference to arg1 for return probes that potentially > hit tail calls ? > > -r > > > vitezslav batrla writes: > > Hello everybody, > > > > Has anyone seen this: > > > > here is disassembled function before probe pidXXX::getpassphrase:return was aplied: > > > > > getpassphrase::dis > > libc.so.1`getpassphrase: mov %o7, %g1 > > libc.so.1`getpassphrase+4: mov 0x100, %o1 > > libc.so.1`getpassphrase+8: call +8 <libc.so.1`__getpass> > > libc.so.1`getpassphrase+0xc: mov %g1, %o7 > > > > And here it is disassembled after probe pidXXX::getpassphrase:return was aplied: > > > > libc.so.1`getpassphrase: mov %o7, %g1 > > libc.so.1`getpassphrase+4: mov 0x100, %o1 > > libc.so.1`getpassphrase+8: call +8 <libc.so.1`__getpass> > > libc.so.1`getpassphrase+0xc: ta 0x38 > > > > It look like this function has no frame (or how it is called correctly?) and dtrace puts the return probe in the delay slot resulting in bad return value in arg1. Is it known problem or not ? > > > > Btw: I''m running S10GA > > > > Have a nice day, > > > > Vita > > > > > > > > > > _______________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss at opensolaris.org >
Hi Vita, The tail-call return probe is a bit of a lie, but not much -- the function is done executing and the called function is never going to return do it. We also wanted to make sure there was a return probe for every entry probe so that flowindent would balance properly. Perhaps we could add an argument to return probes in fbt and pid that indicated that the return was a tail call and therefore the returned value was inaccurate. Adam On Thu, Sep 01, 2005 at 04:31:28PM +0200, vitezslav batrla wrote:> Why not forbid return probes in tail calls at all and display an error instead (or don''t match them)? In fact, this probe is executed somewhere between the entry and the return. Or am I wrong? > > - Vita > > On Thu, 2005-09-01 at 15:52, Roch Bourbonnais - Performance Engineering wrote: > > Correct, Dtrace does not set arg1 correctly for return probes that correspond to > > tail calls. > > > > iteam: could we just forbid reference to arg1 for return probes that potentially > > hit tail calls ? > > > > -r > > > > > > vitezslav batrla writes: > > > Hello everybody, > > > > > > Has anyone seen this: > > > > > > here is disassembled function before probe pidXXX::getpassphrase:return was aplied: > > > > > > > getpassphrase::dis > > > libc.so.1`getpassphrase: mov %o7, %g1 > > > libc.so.1`getpassphrase+4: mov 0x100, %o1 > > > libc.so.1`getpassphrase+8: call +8 <libc.so.1`__getpass> > > > libc.so.1`getpassphrase+0xc: mov %g1, %o7 > > > > > > And here it is disassembled after probe pidXXX::getpassphrase:return was aplied: > > > > > > libc.so.1`getpassphrase: mov %o7, %g1 > > > libc.so.1`getpassphrase+4: mov 0x100, %o1 > > > libc.so.1`getpassphrase+8: call +8 <libc.so.1`__getpass> > > > libc.so.1`getpassphrase+0xc: ta 0x38 > > > > > > It look like this function has no frame (or how it is called correctly?) and dtrace puts the return probe in the delay slot resulting in bad return value in arg1. Is it known problem or not ? > > > > > > Btw: I''m running S10GA > > > > > > Have a nice day, > > > > > > Vita > > > > > > > > > > > > > > > _______________________________________________ > > > dtrace-discuss mailing list > > > dtrace-discuss at opensolaris.org > > > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Hey Vita, The documentation should be updated. I''ll file a bug. Adam On Thu, Sep 01, 2005 at 04:42:08PM +0200, vitezslav batrla wrote:> Thanks, for showing me the term "tail call". Now my life is much better :) > > Ok, I have found it in the documentation: > > return Probes > A return probes fires when the traced function returns or makes a tail call to another function. The value for arg0 is the offset in the function of the return instruction; arg1 holds the return value. > > IMHO there should be that arg1 holds "some" value in the case of the tail call, depending on the function code. It could be easily e.g. an input argument. > > - Vita > > > On Thu, 2005-09-01 at 15:52, Roch Bourbonnais - Performance Engineering wrote: > > Correct, Dtrace does not set arg1 correctly for return probes that correspond to > > tail calls. > > > > iteam: could we just forbid reference to arg1 for return probes that potentially > > hit tail calls ? > > > > -r > > > > > > vitezslav batrla writes: > > > Hello everybody, > > > > > > Has anyone seen this: > > > > > > here is disassembled function before probe pidXXX::getpassphrase:return was aplied: > > > > > > > getpassphrase::dis > > > libc.so.1`getpassphrase: mov %o7, %g1 > > > libc.so.1`getpassphrase+4: mov 0x100, %o1 > > > libc.so.1`getpassphrase+8: call +8 <libc.so.1`__getpass> > > > libc.so.1`getpassphrase+0xc: mov %g1, %o7 > > > > > > And here it is disassembled after probe pidXXX::getpassphrase:return was aplied: > > > > > > libc.so.1`getpassphrase: mov %o7, %g1 > > > libc.so.1`getpassphrase+4: mov 0x100, %o1 > > > libc.so.1`getpassphrase+8: call +8 <libc.so.1`__getpass> > > > libc.so.1`getpassphrase+0xc: ta 0x38 > > > > > > It look like this function has no frame (or how it is called correctly?) and dtrace puts the return probe in the delay slot resulting in bad return value in arg1. Is it known problem or not ? > > > > > > Btw: I''m running S10GA > > > > > > Have a nice day, > > > > > > Vita > > > > > > > > > > > > > > > _______________________________________________ > > > dtrace-discuss mailing list > > > dtrace-discuss at opensolaris.org > > > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl