OpenSolaris

Printable Version Enter a New Search
Bug ID 5099633
Synopsis argN and args[N] are not equivalent in the dtrace pid provider
State 8-Fix Available (Fix has been made (either putback, or just prior))
Category:Subcategory doc:dtrace
Keywords
Responsible Engineer Paul Echeverri
Reported Against s10_68
Duplicate Of
Introduced In
Commit to Fix s10u6_fcs
Fixed In s10u6_fcs
Release Fixed
Related Bugs
Submit Date 9-September-2004
Last Update Date 28-August-2008
Description
From an email exchange with Mike Shapiro:

># dtrace -n 'pid'$$':libc.so:write:entry { printf("%d\n", arg2); }'
>> dtrace: description 'pid106055:libc.so:write:entry ' matched 1 probe
>> ^C
>> 
>> # dtrace -n 'pid'$$':libc.so:write:entry { printf("%d\n", args[2]); }'
>> dtrace: invalid probe specifier pid106055:libc.so:write:entry { 
>> printf("%d\n", args[2]); }: in action list: no args[ ] are available for 
>> probe pid106055:libc.so.1:write:entry
>> 
>> I thought that argN and args[N] were equivalent?

They are not.  argN gives you the raw unfiltered values as int64_t.
args[N] gives you the C arguments with the appropriate type, but
only if we know that using CTF.  We do not yet support doing that
for the PID provider; this will most likely appear in an S10 update.

>> How come that in the 
>> pid provider they don't appear to be?  It was suggested to me that the 
>> reason that args[] doesn't work is because it is typed, and that dtrace 
>> doesn't read the userland CTF in libc so it doesn't know the type 
>> information for args[] - is that correct?

Yes.

>> If so, the documentation should probably be modified to make this clear 
>> - the pid provider section doesn't mention anything about this.

File a bug in the doc category and we'll try to address this in the
final revision of the answerbook.
Work Around
N/A
Comments
N/A