dtrace discuss - Feb 2009 - How many arguments does fbt actually retrieve?

How many arguments, either in argN or args[N], does fbt actually retrieve?  Does
it depend on the machine arch and/or kernel ISA size?

The Guide seems to say arg0-9 are valid, but I can''t see that happening
in
fbt_invop/dtrace_probe.

On Wed, Feb 25, 2009 at 05:24:08PM -0800, Dan Mick
wrote:
> How many arguments, either in argN or args[N], does fbt actually retrieve?
> Does it depend on the machine arch and/or kernel ISA size?
>
> The Guide seems to say arg0-9 are valid, but I can''t see that
happening in
> fbt_invop/dtrace_probe.
arg0-9 are valid and the args[] array gets arguments beyond that.
You''ll
see the first 5 in fbt_invop()/dtrace_probe(); the rest we grab by groveling
through the stack.

Adam

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

Adam Leventhal wrote:
> On Wed, Feb 25, 2009 at 05:24:08PM -0800, Dan Mick wrote:
>> How many arguments, either in argN or args[N], does fbt actually
retrieve?
>> Does it depend on the machine arch and/or kernel ISA size?
>>
>> The Guide seems to say arg0-9 are valid, but I can''t see that
happening in
>> fbt_invop/dtrace_probe.
> 
> arg0-9 are valid and the args[] array gets arguments beyond that.
You''ll
> see the first 5 in fbt_invop()/dtrace_probe(); the rest we grab by
groveling
> through the stack.
..in dtrace_dif_variable.  I see.

Followup question:

Mike Corcoran noticed that args[] array types/indices seem to be invalid for fbt
probes on 32-bit kernels that have 64-bit arguments.  It looks like argN are 
32-bit values, and args[N] are also 32-bit, so the 64-bit arg is contained in 
two argN or args[N] elements.  Is this known?

(specifically, he was looking at arg5/args[5] of map_addr_proc, and finding it 
contained arg 4; this is because the offset_t arg, which is a longlong_t, is 
apparently split across two 32-bit args.)

> Mike Corcoran noticed that args[] array types/indices seem to be invalid 
> for fbt probes on 32-bit kernels that have 64-bit arguments.  It looks like
> argN are 32-bit values, and args[N] are also 32-bit, so the 64-bit arg is 
> contained in two argN or args[N] elements.  Is this known?
>
> (specifically, he was looking at arg5/args[5] of map_addr_proc, and finding
> it contained arg 4; this is because the offset_t arg, which is a 
> longlong_t, is apparently split across two 32-bit args.)
This is a longstanding bug that I first filed over 5 years ago:

  4977683 64-bit arguments on 32-bit kernels confuse argN/args[N]

It''s a pretty significant pain to fix and fortunately not that many
people
have tripped over it. Further, you can work around the problem though it
can be quite surprising.

Adam

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

Adam Leventhal wrote:
>> Mike Corcoran noticed that args[] array types/indices seem to be
invalid
>> for fbt probes on 32-bit kernels that have 64-bit arguments.  It looks
like
>> argN are 32-bit values, and args[N] are also 32-bit, so the 64-bit arg
is
>> contained in two argN or args[N] elements.  Is this known?
>>
>> (specifically, he was looking at arg5/args[5] of map_addr_proc, and
finding
>> it contained arg 4; this is because the offset_t arg, which is a 
>> longlong_t, is apparently split across two 32-bit args.)
> 
> This is a longstanding bug that I first filed over 5 years ago:
> 
>   4977683 64-bit arguments on 32-bit kernels confuse argN/args[N]
> 
> It''s a pretty significant pain to fix and fortunately not that
many people
> have tripped over it. Further, you can work around the problem though it
> can be quite surprising.
I can imagine fixing it is challenging.  Would it be possible to detect the 
problem and issue a warning, at least?

I''m sure I''ve been confused by this in the past, and ended up
deciding that only
a certain number of arguments were valid, or giving up and finding a different 
way to probe without realizing what was happening.