Hi,
Quickie, I hope. Shouldn''t arg0 be a signed int?? From what I can see
running this quick line to check for failed syscalls, it looks like
it''s
an unsigned int??
bash-3.00# dtrace -n ''syscall:::return /arg0 == -1/ {@[probefunc] =
count();}''
dtrace: description ''syscall:::return '' matched 227 probes
^C
Which is a bit strange, I should have some failed syscalls. So if I add
a type cast for arg0 to int:
bash-3.00# dtrace -n ''syscall:::return /(int)arg0 == -1/ {@[probefunc]
=
count();}''
dtrace: description ''syscall:::return '' matched 227 probes
^C
lwp_cond_wait 2
p_online 31
pollsys 64
lwp_park 84
ioctl 127
read 480
Now it looks more like what I expected. So it looks like arg0 in this
case is an unsigned int.
bash-3.00# more /etc/release
Solaris Nevada snv_42 X86
Copyright 2006 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 12 June 2006
And I''m booting 32 bit due to my network card.
Cheers,
Peter
--
OpenSolaris: Innovation Matters <http://www.opensolaris.org> *Peter
Karlsson *
*Solaris Technology Evangelist*
*Sun Microsystems*
Phone: +65 62392 625 / x58625
Mobile:+65 9061 7764
Email: Peter.Karlsson at Sun.COM
Hi Peter, The argN variables are always unsigned 64-bit quantities. Ideally arg[0] would be a signed 32-bit integer in the case you describe, but we don''t have types for syscall provider probes. Adam On Tue, Jul 18, 2006 at 10:59:32PM +0800, Peter Karlsson wrote:> Hi, > > Quickie, I hope. Shouldn''t arg0 be a signed int?? From what I can see > running this quick line to check for failed syscalls, it looks like it''s > an unsigned int?? > > bash-3.00# dtrace -n ''syscall:::return /arg0 == -1/ {@[probefunc] = > count();}'' > dtrace: description ''syscall:::return '' matched 227 probes > ^C > > Which is a bit strange, I should have some failed syscalls. So if I add > a type cast for arg0 to int: > bash-3.00# dtrace -n ''syscall:::return /(int)arg0 == -1/ {@[probefunc] = > count();}'' > dtrace: description ''syscall:::return '' matched 227 probes > ^C > > lwp_cond_wait 2 > p_online 31 > pollsys 64 > lwp_park 84 > ioctl 127 > read 480 > > Now it looks more like what I expected. So it looks like arg0 in this > case is an unsigned int. > > bash-3.00# more /etc/release > Solaris Nevada snv_42 X86 > Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 12 June 2006 > > And I''m booting 32 bit due to my network card. > > Cheers, > Peter > > -- > OpenSolaris: Innovation Matters <http://www.opensolaris.org> *Peter > Karlsson * > *Solaris Technology Evangelist* > *Sun Microsystems* > Phone: +65 62392 625 / x58625 > Mobile:+65 9061 7764 > Email: Peter.Karlsson at Sun.COM > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Hi Adam,
The thing that kind of confuses me a bit is that when in 64bit mode, it
looks like an signed int, so the predicate /arg0 == -1/ works without
having to typcast arg0 and when you do a printf("%d", arg0), the
output
is -1. Well I might just be tired :)
Cheers,
Peter
Adam Leventhal wrote:> Hi Peter,
>
> The argN variables are always unsigned 64-bit quantities. Ideally arg[0]
> would be a signed 32-bit integer in the case you describe, but we
don''t
> have types for syscall provider probes.
>
> Adam
>
> On Tue, Jul 18, 2006 at 10:59:32PM +0800, Peter Karlsson wrote:
>
>> Hi,
>>
>> Quickie, I hope. Shouldn''t arg0 be a signed int?? From what I
can see
>> running this quick line to check for failed syscalls, it looks like
it''s
>> an unsigned int??
>>
>> bash-3.00# dtrace -n ''syscall:::return /arg0 == -1/
{@[probefunc] =
>> count();}''
>> dtrace: description ''syscall:::return '' matched 227
probes
>> ^C
>>
>> Which is a bit strange, I should have some failed syscalls. So if I add
>> a type cast for arg0 to int:
>> bash-3.00# dtrace -n ''syscall:::return /(int)arg0 == -1/
{@[probefunc] =
>> count();}''
>> dtrace: description ''syscall:::return '' matched 227
probes
>> ^C
>>
>> lwp_cond_wait 2
>> p_online 31
>> pollsys 64
>> lwp_park 84
>> ioctl 127
>> read 480
>>
>> Now it looks more like what I expected. So it looks like arg0 in this
>> case is an unsigned int.
>>
>> bash-3.00# more /etc/release
>> Solaris Nevada snv_42 X86
>> Copyright 2006 Sun Microsystems, Inc. All Rights Reserved.
>> Use is subject to license terms.
>> Assembled 12 June 2006
>>
>> And I''m booting 32 bit due to my network card.
>>
>> Cheers,
>> Peter
>>
>> --
>> OpenSolaris: Innovation Matters <http://www.opensolaris.org>
*Peter
>> Karlsson *
>> *Solaris Technology Evangelist*
>> *Sun Microsystems*
>> Phone: +65 62392 625 / x58625
>> Mobile:+65 9061 7764
>> Email: Peter.Karlsson at Sun.COM
>>
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>>
>
>
Hi Peter,
On 64-bit kernels, the argN variables are always 64-bit unsigned integers
(and 32-bit unsigned ints on 32-bit kernels). So:
# dtrace -n ''fbt::polllock:return/(int)arg1 == -1/{
printf("%d", arg1); }''
1 12314 polllock:return 4294967295
1 12314 polllock:return 4294967295
- ahl
On Wed, Jul 19, 2006 at 08:37:59PM +0800, Peter Karlsson
wrote:> Hi Adam,
>
> The thing that kind of confuses me a bit is that when in 64bit mode, it
> looks like an signed int, so the predicate /arg0 == -1/ works without
> having to typcast arg0 and when you do a printf("%d", arg0), the
output
> is -1. Well I might just be tired :)
>
> Cheers,
> Peter
>
> Adam Leventhal wrote:
> >Hi Peter,
> >
> >The argN variables are always unsigned 64-bit quantities. Ideally
arg[0]
> >would be a signed 32-bit integer in the case you describe, but we
don''t
> >have types for syscall provider probes.
> >
> >Adam
> >
> >On Tue, Jul 18, 2006 at 10:59:32PM +0800, Peter Karlsson wrote:
> >
> >>Hi,
> >>
> >>Quickie, I hope. Shouldn''t arg0 be a signed int?? From
what I can see
> >>running this quick line to check for failed syscalls, it looks like
it''s
> >>an unsigned int??
> >>
> >>bash-3.00# dtrace -n ''syscall:::return /arg0 == -1/
{@[probefunc] =
> >>count();}''
> >>dtrace: description ''syscall:::return '' matched
227 probes
> >>^C
> >>
> >>Which is a bit strange, I should have some failed syscalls. So if I
add
> >>a type cast for arg0 to int:
> >>bash-3.00# dtrace -n ''syscall:::return /(int)arg0 == -1/
{@[probefunc] =
> >>count();}''
> >>dtrace: description ''syscall:::return '' matched
227 probes
> >>^C
> >>
> >> lwp_cond_wait
2
> >> p_online
31
> >> pollsys
64
> >> lwp_park
84
> >> ioctl
127
> >> read
480
> >>
> >>Now it looks more like what I expected. So it looks like arg0 in
this
> >>case is an unsigned int.
> >>
> >>bash-3.00# more /etc/release
> >> Solaris Nevada snv_42 X86
> >> Copyright 2006 Sun Microsystems, Inc. All Rights
Reserved.
> >> Use is subject to license terms.
> >> Assembled 12 June 2006
> >>
> >>And I''m booting 32 bit due to my network card.
> >>
> >>Cheers,
> >>Peter
> >>
> >>--
> >>OpenSolaris: Innovation Matters <http://www.opensolaris.org>
*Peter
> >>Karlsson *
> >>*Solaris Technology Evangelist*
> >>*Sun Microsystems*
> >>Phone: +65 62392 625 / x58625
> >>Mobile:+65 9061 7764
> >>Email: Peter.Karlsson at Sun.COM
> >>
> >>_______________________________________________
> >>dtrace-discuss mailing list
> >>dtrace-discuss at opensolaris.org
> >>
> >
> >
--
Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Victor Latushkin
2006-Jul-25 22:13 UTC
[dtrace-discuss] Re: arg0 on return from faild syscall
Hi Adam, I found the same issue while playing with example scripts from "Solaris Internals" chapter on DTrace. There is example script showing how to use return value from the syscall. The point is that it works fine on 64-bit kernels and works incorrectly on 32-bit kernels. That is, negative 32-bit return values are not sign-extended as appropriate into 64-bit signed integer so for -1 you get 4294967295 as a result and comparison to -1 fails (but comparison of (2^64)-1 to -1 works fine meaning these values are considered equal). In case of two 32-bit return values they are combined in a single 64-bit value which one needs to split into parts to get meaningful results. For me this is a bug unless it is documented somewhere as a feature. Please correct me if I misunderstand something. Victor> Hi Peter, > > The argN variables are always unsigned 64-bit > quantities. Ideally arg[0] > would be a signed 32-bit integer in the case you > describe, but we don''t > have types for syscall provider probes. > > Adam > > On Tue, Jul 18, 2006 at 10:59:32PM +0800, Peter > Karlsson wrote: > > Hi, > > > > Quickie, I hope. Shouldn''t arg0 be a signed int?? > From what I can see > > running this quick line to check for failed > syscalls, it looks like it''s > > an unsigned int?? > > > > bash-3.00# dtrace -n ''syscall:::return /arg0 == -1/ > {@[probefunc] = > > count();}'' > > dtrace: description ''syscall:::return '' matched 227 > probes > > ^C > > > > Which is a bit strange, I should have some failed > syscalls. So if I add > > a type cast for arg0 to int: > > bash-3.00# dtrace -n ''syscall:::return /(int)arg0 > == -1/ {@[probefunc] = > > count();}'' > > dtrace: description ''syscall:::return '' matched 227 > probes > > ^C > > > > lwp_cond_wait > 2 > 31 > > 4 > > lwp_park > > 4 > > ioctl > > 27 > > read > > 80 > > > > Now it looks more like what I expected. So it looks > like arg0 in this > > case is an unsigned int. > > > > bash-3.00# more /etc/release > > Solaris Nevada snv_42 > X86 > > Copyright 2006 Sun Microsystems, Inc. > All Rights Reserved. > Use is subject to license > terms. > Assembled 12 June 2006 > ue to my network card. > > > > Cheers, > > Peter > > > > -- > > OpenSolaris: Innovation Matters > <http://www.opensolaris.org> *Peter > > Karlsson * > > *Solaris Technology Evangelist* > > *Sun Microsystems* > > Phone: +65 62392 625 / x58625 > > Mobile:+65 9061 7764 > > Email: Peter.Karlsson at Sun.COM > > > > _______________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss at opensolaris.org > > -- > Adam Leventhal, Solaris Kernel Development > http://blogs.sun.com/ahl > _________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >This message posted from opensolaris.org
Adam Leventhal
2006-Jul-26 17:07 UTC
[dtrace-discuss] Re: arg0 on return from faild syscall
Hi Victor, I misspoke earlier: the argN variables are always 64-bit signed quantities on all ISAs and all datamodels. I was confused because the arguments to the dtrace_probe() function (the function that all providers call when a probe is hit) are of type uintptr_t (unsigned long). Values from the provider are treated as raw unsigned values which are then exposed in the argN variables. System call return values are treated as 64-bit signed integers. On 32-bit kernels, passing the return value to dtrace_probe() as a uintptr_t truncates the value, and it is then expanded to 64-bit without sign-extension (since it''s treated as an unsigned value). I think the bug is in the script -- since the syscall provider doesn''t provide typed arguments, the consumer needs to cast the raw argument (arg0) to the actual return type (int). Adam On Tue, Jul 25, 2006 at 03:13:25PM -0700, Victor Latushkin wrote:> Hi Adam, > > I found the same issue while playing with example scripts from "Solaris Internals" chapter on DTrace. > There is example script showing how to use return value from the syscall. > > The point is that it works fine on 64-bit kernels and works incorrectly on 32-bit kernels. That is, negative 32-bit return values are not sign-extended as appropriate into 64-bit signed integer so for -1 you get 4294967295 as a result and comparison to -1 fails (but comparison of (2^64)-1 to -1 works fine meaning these values are considered equal). In case of two 32-bit return values they are combined in a single 64-bit value which one needs to split into parts to get meaningful results. > > For me this is a bug unless it is documented somewhere as a feature. > > Please correct me if I misunderstand something. > > Victor > > > Hi Peter, > > > > The argN variables are always unsigned 64-bit > > quantities. Ideally arg[0] > > would be a signed 32-bit integer in the case you > > describe, but we don''t > > have types for syscall provider probes. > > > > Adam > > > > On Tue, Jul 18, 2006 at 10:59:32PM +0800, Peter > > Karlsson wrote: > > > Hi, > > > > > > Quickie, I hope. Shouldn''t arg0 be a signed int?? > > From what I can see > > > running this quick line to check for failed > > syscalls, it looks like it''s > > > an unsigned int?? > > > > > > bash-3.00# dtrace -n ''syscall:::return /arg0 == -1/ > > {@[probefunc] = > > > count();}'' > > > dtrace: description ''syscall:::return '' matched 227 > > probes > > > ^C > > > > > > Which is a bit strange, I should have some failed > > syscalls. So if I add > > > a type cast for arg0 to int: > > > bash-3.00# dtrace -n ''syscall:::return /(int)arg0 > > == -1/ {@[probefunc] = > > > count();}'' > > > dtrace: description ''syscall:::return '' matched 227 > > probes > > > ^C > > > > > > lwp_cond_wait > > 2 > > 31 > > > > 4 > > > lwp_park > > > > 4 > > > ioctl > > > > 27 > > > read > > > > 80 > > > > > > Now it looks more like what I expected. So it looks > > like arg0 in this > > > case is an unsigned int. > > > > > > bash-3.00# more /etc/release > > > Solaris Nevada snv_42 > > X86 > > > Copyright 2006 Sun Microsystems, Inc. > > All Rights Reserved. > > Use is subject to license > > terms. > > Assembled 12 June 2006 > > ue to my network card. > > > > > > Cheers, > > > Peter > > > > > > -- > > > OpenSolaris: Innovation Matters > > <http://www.opensolaris.org> *Peter > > > Karlsson * > > > *Solaris Technology Evangelist* > > > *Sun Microsystems* > > > Phone: +65 62392 625 / x58625 > > > Mobile:+65 9061 7764 > > > Email: Peter.Karlsson at Sun.COM > > > > > > _______________________________________________ > > > dtrace-discuss mailing list > > > dtrace-discuss at opensolaris.org > > > > -- > > Adam Leventhal, Solaris Kernel Development > > http://blogs.sun.com/ahl > > _________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss at opensolaris.org > > > > > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl