dtrace discuss - Feb 2009 - unbalanced fbt output when tracing uiomove/xcopyin/copyin_more

I''m flow tracing and computing some inclusive/exclusive elapsed
function times
and I''ve come across a problem. Here''s an excerpt of the
problematic output:

-> uiomove
...
<- copyin_more
<- uiomove

There is no fbt:::entry output for copyin_more but there is output for
fbt:::return.
After perusing the source/assembler, I''ve discovered the following:

- uiomove calls xcopyin which has no entry/return probes
- xcopyin calls copyin_more+0xc (labeled as .do_copyin in asm): 
      xcopyin+0xe0:       ba,pt  %xcc, SUNW,UltraSPARC-IIIi:copyin_more+0xc
- copyin_more does have entry/return probes, but the entry probe
doesn''t fire,
presumably because we''re not entering the function at +0x0

This leads to "unbalanced" output and is seriously screwing with the
stack-depth
logic in my code. I might be able to hack around this, but I''d prefer
something
elegant. Any ideas?
-- 
This message posted from opensolaris.org

OK, that got cut off for some reason ... here''s the rest of the post:

There is no fbt:::entry output for copyin_more but there is output for 
fbt:::return. After perusing the source/assembler, I''ve discovered the
following:

- uiomove calls xcopyin which has no entry/return probes
- xcopyin calls copyin_more+0xc (labeled as .do_copyin in asm): 
      xcopyin+0xe0:       ba,pt  %xcc, SUNW,UltraSPARC-IIIi:copyin_more+0xc
- copyin_more does have entry/return probes, but the entry probe
doesn''t fire,
presumably because we''re not entering the function at +0x0

This leads to "unbalanced" output and is seriously screwing with the
stack-depth
logic in my code. I might be able to hack around this, but I''d prefer
something
elegant. Any ideas?
-- 
This message posted from opensolaris.org