dtrace discuss - Mar 2007 - Functions that cannot be traced by FBT under x86

Hi All:

In Solaris Dtrace User Guide, page 218, it says,
"Functions that do not create a stack frame on x86 systems cannot be
instrumented by FBT."

Then what are these functions?
What characteristics do they have?


Regards
TJ

???? (Euler Tao) wrote:
> In Solaris Dtrace User Guide, page 218, it says,
> "Functions that do not create a stack frame on x86 systems cannot be
> instrumented by FBT."
> 
> Then what are these functions?
> What characteristics do they have?
A first approximation answer to this question is:

functions compiled by gcc when using

   -fomit-frame-pointer        When possible do not generate stack frames



Yes, this is an optimization technique. Imnsho it''s
not a good one if you want to be able to debug any
problem with your code - whether using dtrace or any
other debugging tool.


cheers,
James C. McPherson
--
Solaris kernel software engineer
Sun Microsystems

James C. McPherson wrote:
> ???? (Euler Tao) wrote:
>> In Solaris Dtrace User Guide, page 218, it says,
>> "Functions that do not create a stack frame on x86 systems cannot
be
>> instrumented by FBT."
>>
>> Then what are these functions?
>> What characteristics do they have?
> 
> A first approximation answer to this question is:
> 
> functions compiled by gcc when using
> 
>   -fomit-frame-pointer        When possible do not generate stack frames
> 
> 
> 
> Yes, this is an optimization technique. Imnsho it''s
> not a good one if you want to be able to debug any
> problem with your code - whether using dtrace or any
> other debugging tool.
There are also a bunch of assembly leaf routines that don''t create
stack
frames because they 1) are leaf, and so don''t need to prepare for their
callees, and 2) are in assembly for efficiency, and the stack frame 
doesn''t help them or the system as a whole, only hurts.

Unfortunately for me, this includes all the ddi_get/put{size} routines, 
which I''d dearly love to be able to instrument in an ad-hoc way.  But 
there are plenty of others.

On Sat, 2007-03-10 at 11:49 -0800, Dan Mick wrote:
> 
> Unfortunately for me, this includes all the ddi_get/put{size}
> routines, 
> which I''d dearly love to be able to instrument in an ad-hoc way. 
But
> there are plenty of others.
> 
I often add debug wrappers around these in drivers I am debugging just
for this.  Would be nice if the kernel/dtrace had a mechanism to
dynamically create wrappers with stack frames around these leafs. 

Marty

On Sat, Mar 10, 2007 at 08:07:51PM +1100, James C. McPherson
wrote:
> ???? (Euler Tao) wrote:
> >In Solaris Dtrace User Guide, page 218, it says,
> >"Functions that do not create a stack frame on x86 systems cannot
be
> >instrumented by FBT."
> >
> >Then what are these functions?
> >What characteristics do they have?
> 
> A first approximation answer to this question is:
> 
> functions compiled by gcc when using
> 
>   -fomit-frame-pointer        When possible do not generate stack frames
Nothing in the kernel should be compiled with that option enabled; while
it''s true that this would cause a function to be generated in such a
way that
fbt would ignore it, that''s not actually the case for any functions
you''ll
encounter. The choice for fbt to ignore functions that don''t push a
stack
frame is a conservative heuristic to ensure that we don''t instrument
any
functions that may be unsafe (where DTrace''s requirement for safety in
this
case is -- surprise -- the ability to push a stack frame).

It''s worth noting that another heuristic we could (and should) apply is
that
functions written in C are safe to instrument. Functions that need to operate
in tricky spots must be written in assembly to ensure the compiler
doesn''t
do something that would be invalid under the given conditions. We use this
for SPARC since the compiler will may generate leaf functions that
don''t
bother pushing a stack frame; there''s an open bug to do this on amd64
on
which the compiler performs a similar optimization.

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl