Discussion:
dtrace & tail calls
Robert Harris
2010-06-10 22:26:42 UTC
Permalink
If I have foo(), where

foo() {
return(bar());
}

then should I expect anything unusual about args[1]
in fbt::foo:return? Should I expect args[1] in such
a probe to give me X where

X = foo()

?

I ask after finding something odd about the following
code in mapin():

145 pfnum = hat_getpfnum(as->a_hat, addr);
146 if (pf_is_memory(pfnum)) {

dtrace alleged that the return value of hat_getpfnum()
differed from the argument to pf_is_memory(); recompiling
with cmn_err() showed that the latter was correct. The value
of args[1] in hat_getpfnum:return looked like the second
argument passed in.

Robert
Adam Leventhal
2010-06-11 21:44:32 UTC
Permalink
Hey Robert,
Post by Robert Harris
If I have foo(), where
foo() {
return(bar());
}
then should I expect anything unusual about args[1]
in fbt::foo:return? Should I expect args[1] in such
a probe to give me X where
X = foo()
If the code above were compiled into a tail call, the foo:return probe would fire before the bar:entry probe. The value of arg1 or args[1] will not contain the value returned to the caller of foo().

To trace that value, one can write a simple script:

foo:entry
{
self->follow = 1;
}

bar:return
/self->follow/
{
trace(arg1);
self->follow = 0;
}

This applies both for user-land and the kernel.

Adam

--
Adam Leventhal, Fishworks http://blogs.sun.com/ahl
Robert Harris
2010-06-14 16:38:47 UTC
Permalink
Hi Adam,
Post by Adam Leventhal
If the code above were compiled into a tail call, the
foo:return probe would fire before the bar:entry probe.
The value of arg1 or args[1] will not contain the value
returned to the caller of foo().
Many thanks for the clarification. May I suggest that
the fbt chapter in the DTrace wiki be updated to reflect
this? The section on Tail-call Optimization discusses the
difference in ordering, but I don't think that the effect
on args[1] follows.

Regards,

Robert
Adam Leventhal
2010-06-22 01:18:24 UTC
Permalink
Post by Robert Harris
Post by Adam Leventhal
If the code above were compiled into a tail call, the
foo:return probe would fire before the bar:entry probe.
The value of arg1 or args[1] will not contain the value
returned to the caller of foo().
Many thanks for the clarification. May I suggest that
the fbt chapter in the DTrace wiki be updated to reflect
this? The section on Tail-call Optimization discusses the
difference in ordering, but I don't think that the effect
on args[1] follows.
Sounds good. If you -- or anyone else -- has suggestions for how to improve the documentation here, please follow the normal procedure of posting to the list so the community can approve before updating the wiki.

Thanks, and apologies for the confusing behavior.

Adam

--
Adam Leventhal, Fishworks http://blogs.sun.com/ahl
Loading...