dtrace discuss - Jan 2007 - dtrace syscall:::return arg0 weidness on b56 ( x86)

At the moment I am attending course SA327 ( dtrace)
and I am doing the excercises on my macbook running  b56 on parallels.

In one excercise we have to list failing system calls using
a predicate: /arg0 == -1/ and this never matches on my system.
When I change the test into / arg0 == 429496729 / it matches.
On a Acer Ferrari running S10u3 the test for -1 works.

Any idea if this is a bug in b56 or what it might be otherwise ??

Regards
	Paul

>
>At the moment I am attending course SA327 ( dtrace)
>and I am doing the excercises on my macbook running  b56 on parallels.
>
>In one excercise we have to list failing system calls using
>a predicate: /arg0 == -1/ and this never matches on my system.
>When I change the test into / arg0 == 429496729 / it matches.
>On a Acer Ferrari running S10u3 the test for -1 works.
>
>Any idea if this is a bug in b56 or what it might be otherwise ??
Are both running 64 bit kernels or is this 32 vs 64 bit?

Casper

On 31-jan-2007, at 11:41, Casper.Dik at Sun.COM wrote:
>
>>
>> At the moment I am attending course SA327 ( dtrace)
>> and I am doing the excercises on my macbook running  b56 on  
>> parallels.
>>
>> In one excercise we have to list failing system calls using
>> a predicate: /arg0 == -1/ and this never matches on my system.
>> When I change the test into / arg0 == 429496729 / it matches.
>> On a Acer Ferrari running S10u3 the test for -1 works.
>>
>> Any idea if this is a bug in b56 or what it might be otherwise ??
>
> Are both running 64 bit kernels or is this 32 vs 64 bit?
>
32 bit, and I think I found the problem and answer in the mail  
archives..
You have to cat the arg0 on syscall:::return to int. On 64 bit it  
does not
matter on 32 bit it definitely does...
I''ll have to file a bug on the training material as all their samples  
and
answers are missing the cast.

	Paul

Paul van der Zwan wrote:
> 
> On 31-jan-2007, at 11:41, Casper.Dik at Sun.COM wrote:
> 
>>
>>>
>>> At the moment I am attending course SA327 ( dtrace)
>>> and I am doing the excercises on my macbook running  b56 on
parallels.
>>>
>>> In one excercise we have to list failing system calls using
>>> a predicate: /arg0 == -1/ and this never matches on my system.
>>> When I change the test into / arg0 == 429496729 / it matches.
>>> On a Acer Ferrari running S10u3 the test for -1 works.
>>>
>>> Any idea if this is a bug in b56 or what it might be otherwise ??
>>
>> Are both running 64 bit kernels or is this 32 vs 64 bit?
>>
> 
> 32 bit, and I think I found the problem and answer in the mail archives..
> You have to cat the arg0 on syscall:::return to int. On 64 bit it does not
> matter on 32 bit it definitely does...
> I''ll have to file a bug on the training material as all their
samples and
> answers are missing the cast.
I don''t know ... I looked at random at the manpages for several system 
calls, they all return a signed value. I think the dtrace framework is 
intelligent enough to realise that, and type arg0 accordingly. On my b55 
machine, running 32bit, /arg0 == -1/ works quite OK, so I don''t think
it''s
a bug in the training material.
I haven''t got a 32bit machine running NV b56, so I cannot test the 
behaviour there, but IMO if this has changed, it''s not a bug in the 
training material.

just my 2cents
Michael
-- 
Michael Schuster
Sun Microsystems, Inc.

On 31-jan-2007, at 12:13, Michael Schuster wrote:
> Paul van der Zwan wrote:
>> On 31-jan-2007, at 11:41, Casper.Dik at Sun.COM wrote:
>>>
>>>>
>>>> At the moment I am attending course SA327 ( dtrace)
>>>> and I am doing the excercises on my macbook running  b56 on  
>>>> parallels.
>>>>
>>>> In one excercise we have to list failing system calls using
>>>> a predicate: /arg0 == -1/ and this never matches on my system.
>>>> When I change the test into / arg0 == 429496729 / it matches.
>>>> On a Acer Ferrari running S10u3 the test for -1 works.
>>>>
>>>> Any idea if this is a bug in b56 or what it might be otherwise
??
>>>
>>> Are both running 64 bit kernels or is this 32 vs 64 bit?
>>>
>> 32 bit, and I think I found the problem and answer in the mail  
>> archives..
>> You have to cat the arg0 on syscall:::return to int. On 64 bit it  
>> does not
>> matter on 32 bit it definitely does...
>> I''ll have to file a bug on the training material as all their
>> samples and
>> answers are missing the cast.
>
> I don''t know ... I looked at random at the manpages for several  
> system calls, they all return a signed value. I think the dtrace  
> framework is intelligent enough to realise that, and type arg0  
> accordingly. On my b55 machine, running 32bit, /arg0 == -1/ works  
> quite OK, so I don''t think it''s a bug in the training
material.
> I haven''t got a 32bit machine running NV b56, so I cannot test the
> behaviour there, but IMO if this has changed, it''s not a bug in
the
> training material.

Here is an older mail thread I found which explains the issue.
If that thread is correct it looks like a bug in the training  
material to me :
http://www.opensolaris.org/jive/thread.jspa?messageID=47997&#47997

Regards
	Paul

Paul van der Zwan wrote:
> Here is an older mail thread I found which explains the issue.
> If that thread is correct it looks like a bug in the training material 
> to me :
> http://www.opensolaris.org/jive/thread.jspa?messageID=47997&#47997
ouch ... I lost the "-" somewhere in my testing and did "/arg0 ==
1/",
which of course showed tons of result :-)

Michael
-- 
Michael Schuster
Sun Microsystems, Inc.

Paul,

DTrace User Guide states: "The DTrace variable arg1 for the syscall 
return probes evaluates to the system call?s return value" (p. 41). So, 
the return value is passed in arg1 variable not in arg0.
As for the thread you mentioned - the posters did the same mistake using 
arg0. However, Adam Leventhal gave a script excerpt where arg1 was 
correctly used instead.

Paul van der Zwan wrote:
> 
> On 31-jan-2007, at 12:13, Michael Schuster wrote:
> 
>> Paul van der Zwan wrote:
>>> On 31-jan-2007, at 11:41, Casper.Dik at Sun.COM wrote:
>>>>
>>>>>
>>>>> At the moment I am attending course SA327 ( dtrace)
>>>>> and I am doing the excercises on my macbook running  b56 on
parallels.
>>>>>
>>>>> In one excercise we have to list failing system calls using
>>>>> a predicate: /arg0 == -1/ and this never matches on my
system.
>>>>> When I change the test into / arg0 == 429496729 / it
matches.
>>>>> On a Acer Ferrari running S10u3 the test for -1 works.
>>>>>
>>>>> Any idea if this is a bug in b56 or what it might be
otherwise ??
>>>>
>>>> Are both running 64 bit kernels or is this 32 vs 64 bit?
>>>>
>>> 32 bit, and I think I found the problem and answer in the mail 
>>> archives..
>>> You have to cat the arg0 on syscall:::return to int. On 64 bit it 
>>> does not
>>> matter on 32 bit it definitely does...
>>> I''ll have to file a bug on the training material as all
their samples
>>> and
>>> answers are missing the cast.
>>
>> I don''t know ... I looked at random at the manpages for
several system
>> calls, they all return a signed value. I think the dtrace framework is 
>> intelligent enough to realise that, and type arg0 accordingly. On my 
>> b55 machine, running 32bit, /arg0 == -1/ works quite OK, so I
don''t
>> think it''s a bug in the training material.
>> I haven''t got a 32bit machine running NV b56, so I cannot test
the
>> behaviour there, but IMO if this has changed, it''s not a bug
in the
>> training material.
> 
> 
> Here is an older mail thread I found which explains the issue.
> If that thread is correct it looks like a bug in the training material 
> to me :
> http://www.opensolaris.org/jive/thread.jspa?messageID=47997&#47997
> 
> Regards
>     Paul
> 
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org


-- 
   Anton

Anton Youdkevitch wrote:
> Paul,
> 
> DTrace User Guide states: "The DTrace variable arg1 for the syscall 
> return probes evaluates to the system call?s return value" (p. 41).
So,
> the return value is passed in arg1 variable not in arg0.
ah, but in the chapter on the syscall provider, it says, "For return 
probes, both arg0 and arg1 contain the return value." (p. 223)

so that is not the mistake, I guess (or if, then it''s the doc and not
the
script).

cheers
-- 
Michael Schuster
Sun Microsystems, Inc.

It can be a bit annoying, but since arg0 is a uint64_t you''ll need to
cast
it to  a signed int and then perform the comparison:

/(int)arg0 == -1/

Adam

On Wed, Jan 31, 2007 at 11:34:27AM +0100, Paul van der Zwan
wrote:
> 
> At the moment I am attending course SA327 ( dtrace)
> and I am doing the excercises on my macbook running  b56 on parallels.
> 
> In one excercise we have to list failing system calls using
> a predicate: /arg0 == -1/ and this never matches on my system.
> When I change the test into / arg0 == 429496729 / it matches.
> On a Acer Ferrari running S10u3 the test for -1 works.
> 
> Any idea if this is a bug in b56 or what it might be otherwise ??
> 
> Regards
> 	Paul
> 
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Michael Schuster wrote:
> Anton Youdkevitch wrote:
>> Paul,
>>
>> DTrace User Guide states: "The DTrace variable arg1 for the
syscall
>> return probes evaluates to the system call?s return value" (p.
41).
>> So, the return value is passed in arg1 variable not in arg0.
> 
> ah, but in the chapter on the syscall provider, it says, "For return 
> probes, both arg0 and arg1 contain the return value." (p. 223)
> 
> so that is not the mistake, I guess (or if, then it''s the doc and
not
> the script).
Oops! You are right. Seems to be syscall provider specific property. 
 From the doc I''ve got a feeling that arg1 is always used to put return
value to.
Sorry then. :(

-- 
   Anton

This is a bit of an historical artifact. At first, the syscall provider just
had its return value in arg0, and the fbt and pid providers had their return
values in arg1 (so that we could use arg0 for the offset of the return site).

We inevitably started writing scripts where we wanted to see the return
values from probes in all three providers, and we made this script easier
to write by replicating the syscall return values in arg1 to match fbt and
pid. We debated briefly about removing the return value from arg0, but
decided that it would be less confusing to have the same data in two places
than to have some non-helpful, non-intuitive value in arg0.

This change was made 4/23/2003 according to the DTrace project''s
putback log.

Adam

On Wed, Jan 31, 2007 at 07:32:18PM +0300, Anton Youdkevitch
wrote:
> 
> Michael Schuster wrote:
> >Anton Youdkevitch wrote:
> >>Paul,
> >>
> >>DTrace User Guide states: "The DTrace variable arg1 for the
syscall
> >>return probes evaluates to the system call?s return value" (p.
41).
> >>So, the return value is passed in arg1 variable not in arg0.
> >
> >ah, but in the chapter on the syscall provider, it says, "For
return
> >probes, both arg0 and arg1 contain the return value." (p. 223)
> >
> >so that is not the mistake, I guess (or if, then it''s the doc
and not
> >the script).
> Oops! You are right. Seems to be syscall provider specific property. 
> From the doc I''ve got a feeling that arg1 is always used to put
return
> value to.
> Sorry then. :(
> 
> -- 
>   Anton
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl