dtrace discuss - Aug 2006 - Rationale behind choice of arg variables or args array

I''ve been looking over the documentation and trying to figure out a 
rationale as to why the args array is made available by some probe 
providers and not for others.  Also, why do arguments in the args array 
not always map to the same index as the arg variables.  For example, the 
signal passed to the proc:::signal-send probe is in args[2], but it''s
in
arg1.

This all seems a little confusing and, forgive me, a bit arbitrary.  Of 
course, maybe it''s not arbitrary, and I just can''t see the
pattern.  :-)

Thanks,
Chip

Hi Chip,

The argN arguments are always the raw arguments as passed to the
dtrace_probe() function in the kernel. In addition, some probes have typed
(and translated) arguments which are available in the args[] array.
Statically defined tracing probes (SDT) and their user-land corollary (USDT),
can translate a single raw argument to multiple typed arguments in the
args[] array. This means, we can convert a kthread_t *, say, to a lwpsinfo_t *
and a psinfo_t * (in the case of the proc:::singal-send probe). This
mechanism allows us to take arguments in private kernel types and translate
them to stable argument types.

Ideally, all probes would have typed arguments, but there are some providers
where it would be tricky to get the types. For example, we have CTF data
(which provides argument types) for user-land libraries, but we need to
create some new plumbing to let DTrace use those types. It would also be
great to have types for syscall probes; again, it''s a bunch of work
with
no major technical hurdles.

Adam

On Tue, Aug 15, 2006 at 02:43:57PM -0500, Chip Bennett
wrote:
> I''ve been looking over the documentation and trying to figure out
a
> rationale as to why the args array is made available by some probe 
> providers and not for others.  Also, why do arguments in the args array 
> not always map to the same index as the arg variables.  For example, the 
> signal passed to the proc:::signal-send probe is in args[2], but
it''s in
> arg1.
> 
> This all seems a little confusing and, forgive me, a bit arbitrary.  Of 
> course, maybe it''s not arbitrary, and I just can''t see
the pattern.  :-)
> 
> Thanks,
> Chip
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

OK, I think I get it.  Only the SDT based providers presently have the 
args array as defined in sdt_args.  The real args are the 64-bit argn 
integers.  The args array is a constructed, and sometimes expanded 
version of that.  The only other provider that has the args array 
defined is the fbt provider.  I just read in the USENIX white paper that 
the fbt provider gets that from a kernel service, so no one had to 
construct a special "table" for that (Wow!  Good thing!).  Obviously, 
there must not have been such a kernel service available for syscall 
arguments.  (That would have been nice!)

FYI:  Table 3-1 in the DTrace Guide incorrectly uses read(2) as an 
example of how the args array works.

Thanks!
Chip

Adam Leventhal wrote:
> Hi Chip,
>
> The argN arguments are always the raw arguments as passed to the
> dtrace_probe() function in the kernel. In addition, some probes have typed
> (and translated) arguments which are available in the args[] array.
> Statically defined tracing probes (SDT) and their user-land corollary
(USDT),
> can translate a single raw argument to multiple typed arguments in the
> args[] array. This means, we can convert a kthread_t *, say, to a
lwpsinfo_t *
> and a psinfo_t * (in the case of the proc:::singal-send probe). This
> mechanism allows us to take arguments in private kernel types and translate
> them to stable argument types.
>
> Ideally, all probes would have typed arguments, but there are some
providers
> where it would be tricky to get the types. For example, we have CTF data
> (which provides argument types) for user-land libraries, but we need to
> create some new plumbing to let DTrace use those types. It would also be
> great to have types for syscall probes; again, it''s a bunch of
work with
> no major technical hurdles.
>
> Adam
>
> On Tue, Aug 15, 2006 at 02:43:57PM -0500, Chip Bennett wrote:
>   
>> I''ve been looking over the documentation and trying to figure
out a
>> rationale as to why the args array is made available by some probe 
>> providers and not for others.  Also, why do arguments in the args array
>> not always map to the same index as the arg variables.  For example,
the
>> signal passed to the proc:::signal-send probe is in args[2], but
it''s in
>> arg1.
>>
>> This all seems a little confusing and, forgive me, a bit arbitrary.  Of
>> course, maybe it''s not arbitrary, and I just can''t
see the pattern.  :-)
>>
>> Thanks,
>> Chip
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>>     
>
>

> FYI:  Table 3-1 in the DTrace Guide incorrectly uses read(2) as an 
> example of how the args array works.
Ooops, would you mind filing a bug in doc/dtrace? Thanks.

Adam


On Tue, Aug 15, 2006 at 05:39:10PM -0500, Chip Bennett
wrote:
> OK, I think I get it.  Only the SDT based providers presently have the 
> args array as defined in sdt_args.  The real args are the 64-bit argn 
> integers.  The args array is a constructed, and sometimes expanded 
> version of that.  The only other provider that has the args array 
> defined is the fbt provider.  I just read in the USENIX white paper that 
> the fbt provider gets that from a kernel service, so no one had to 
> construct a special "table" for that (Wow!  Good thing!). 
Obviously,
> there must not have been such a kernel service available for syscall 
> arguments.  (That would have been nice!)
> 
> FYI:  Table 3-1 in the DTrace Guide incorrectly uses read(2) as an 
> example of how the args array works.
> 
> Thanks!
> Chip
> 
> Adam Leventhal wrote:
> >Hi Chip,
> >
> >The argN arguments are always the raw arguments as passed to the
> >dtrace_probe() function in the kernel. In addition, some probes have
typed
> >(and translated) arguments which are available in the args[] array.
> >Statically defined tracing probes (SDT) and their user-land corollary 
> >(USDT),
> >can translate a single raw argument to multiple typed arguments in the
> >args[] array. This means, we can convert a kthread_t *, say, to a 
> >lwpsinfo_t *
> >and a psinfo_t * (in the case of the proc:::singal-send probe). This
> >mechanism allows us to take arguments in private kernel types and
translate
> >them to stable argument types.
> >
> >Ideally, all probes would have typed arguments, but there are some 
> >providers
> >where it would be tricky to get the types. For example, we have CTF
data
> >(which provides argument types) for user-land libraries, but we need to
> >create some new plumbing to let DTrace use those types. It would also
be
> >great to have types for syscall probes; again, it''s a bunch of
work with
> >no major technical hurdles.
> >
> >Adam
> >
> >On Tue, Aug 15, 2006 at 02:43:57PM -0500, Chip Bennett wrote:
> >  
> >>I''ve been looking over the documentation and trying to
figure out a
> >>rationale as to why the args array is made available by some probe 
> >>providers and not for others.  Also, why do arguments in the args
array
> >>not always map to the same index as the arg variables.  For
example, the
> >>signal passed to the proc:::signal-send probe is in args[2], but
it''s in
> >>arg1.
> >>
> >>This all seems a little confusing and, forgive me, a bit arbitrary.
Of
> >>course, maybe it''s not arbitrary, and I just
can''t see the pattern.  :-)
> >>
> >>Thanks,
> >>Chip
> >>_______________________________________________
> >>dtrace-discuss mailing list
> >>dtrace-discuss at opensolaris.org
> >>    
> >
> >  
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl