dtrace discuss - Jun 2009 - garbled arguments with syscall provider.

Hello all,
   I''m currently doing undergraduate research using dtrace at the
University of Wisconsin-Madison, and I had a question concerning DTrace on
Leopard. If the non-Solaris-oriented nature of the question makes this
inappropriate for this list, then I apologize.
I have been using the syscall provider to obtain info about IO, and in nearly
all cases it works correctly. For one particular syscall (open_nocancel)  (and I
realize this is almost definitely OS dependent), I get a garbage string for
arg0, which baffles me, as arg0 should be the pathname for the open call.

My code looks like this:

syscall::open_nocancel:entry
{
        this->now = timestamp - timeZero;
        printf("at %d nsecs %s called %s ", this->now, execname,
probefunc);
        self->path = arg0;
        
}

syscall::open_nocancel:return
{
        printf("with filename:%s and file descriptor %d\n",
copyinstr(self->path), arg1);
        fileNames[arg0] = copyinstr(self->argsPtr->path);
}


I''ve considered the option that arg0 is not what I think it is, but
when I ran this piece of C code:
int fd = syscall(SYS_open_nocancel, "foo.txt", O_RDWR| O_CREAT |
O_TRUNC);
It behaves exactly like a call to open, leading me to believe (perhaps
erroneously) that the arguments should be the same.

Essentially I was wondering two things that would help me understand this.
First, I was wondering how the syscall provider obtains the arguments that
correspond to arg0, arg1, ... argN, as I have been unable to locate this in the
documentation, and also if it could be the case that a memory location
referenced by a syscall argument could be manipulated between the time at which
the entry and the return probes fire. Again, these are probably more OS
implementation related questions than DTrace questions and may be inappropriate
for this mailing list. Thank you very much for your time and patience,
   Michael Vaughn

Sorry, I made an error in the code I sent: copyinstr(self->argsPtr->path)
should be copyinstr(self->path). The old code was left over from me playing
with the FBT provider instead.

----- Original Message -----
From: MICHAEL BENJAMIN VAUGHN <mvaughn at wisc.edu>
Date: Monday, June 1, 2009 11:57 am
Subject: garbled arguments with syscall provider.
To: dtrace-discuss at opensolaris.org
> Hello all,
>    I''m currently doing undergraduate research using dtrace at the 
> University of Wisconsin-Madison, and I had a question concerning 
> DTrace on Leopard. If the non-Solaris-oriented nature of the question 
> makes this inappropriate for this list, then I apologize. 
> I have been using the syscall provider to obtain info about IO, and in 
> nearly all cases it works correctly. For one particular syscall 
> (open_nocancel)  (and I realize this is almost definitely OS 
> dependent), I get a garbage string for arg0, which baffles me, as arg0 
> should be the pathname for the open call.
> 
> My code looks like this:
> 
> syscall::open_nocancel:entry
> {
>         this->now = timestamp - timeZero;
>         printf("at %d nsecs %s called %s ", this->now,
execname, probefunc);
>         self->path = arg0;
>         
> }
> 
> syscall::open_nocancel:return
> {
>         printf("with filename:%s and file descriptor %d\n", 
> copyinstr(self->path), arg1);
>         fileNames[arg0] = copyinstr(self->argsPtr->path);
> }
> 
> 
> I''ve considered the option that arg0 is not what I think it is,
but
> when I ran this piece of C code:
> int fd = syscall(SYS_open_nocancel, "foo.txt", O_RDWR| O_CREAT |
O_TRUNC);
> It behaves exactly like a call to open, leading me to believe (perhaps 
> erroneously) that the arguments should be the same.
> 
> Essentially I was wondering two things that would help me understand 
> this. First, I was wondering how the syscall provider obtains the 
> arguments that correspond to arg0, arg1, ... argN, as I have been 
> unable to locate this in the documentation, and also if it could be 
> the case that a memory location referenced by a syscall argument could 
> be manipulated between the time at which the entry and the return 
> probes fire. Again, these are probably more OS implementation related 
> questions than DTrace questions and may be inappropriate for this 
> mailing list. Thank you very much for your time and patience,
>    Michael Vaughn
>

Sorry for the repeated apologies. I forgot that my mail client isn''t a 
a WYSWYG editor, and as such I left out line breaks. Clearly my
mailing list etiquette needs some work.
Apologies,
   Michael Vaughn

Hi Michael,

AFAIK the input arguments to the syscall aren''t necessarily around any 
more by the time it returns; if you want to keep them you''d need to 
assign a self-> the value; arg0, in particular, is the return value of 
the syscall iirc.

Regards,
Ryan

MICHAEL BENJAMIN VAUGHN wrote:
> Sorry, I made an error in the code I sent:
copyinstr(self->argsPtr->path) should be copyinstr(self->path). The old
code was left over from me playing with the FBT provider instead.
>
> ----- Original Message -----
> From: MICHAEL BENJAMIN VAUGHN <mvaughn at wisc.edu>
> Date: Monday, June 1, 2009 11:57 am
> Subject: garbled arguments with syscall provider.
> To: dtrace-discuss at opensolaris.org
>
>   
>> Hello all,
>>    I''m currently doing undergraduate research using dtrace at
the
>> University of Wisconsin-Madison, and I had a question concerning 
>> DTrace on Leopard. If the non-Solaris-oriented nature of the question 
>> makes this inappropriate for this list, then I apologize. 
>> I have been using the syscall provider to obtain info about IO, and in 
>> nearly all cases it works correctly. For one particular syscall 
>> (open_nocancel)  (and I realize this is almost definitely OS 
>> dependent), I get a garbage string for arg0, which baffles me, as arg0 
>> should be the pathname for the open call.
>>
>> My code looks like this:
>>
>> syscall::open_nocancel:entry
>> {
>>         this->now = timestamp - timeZero;
>>         printf("at %d nsecs %s called %s ", this->now,
execname, probefunc);
>>         self->path = arg0;
>>         
>> }
>>
>> syscall::open_nocancel:return
>> {
>>         printf("with filename:%s and file descriptor %d\n", 
>> copyinstr(self->path), arg1);
>>         fileNames[arg0] = copyinstr(self->argsPtr->path);
>> }
>>
>>
>> I''ve considered the option that arg0 is not what I think it
is, but
>> when I ran this piece of C code:
>> int fd = syscall(SYS_open_nocancel, "foo.txt", O_RDWR|
O_CREAT | O_TRUNC);
>> It behaves exactly like a call to open, leading me to believe (perhaps 
>> erroneously) that the arguments should be the same.
>>
>> Essentially I was wondering two things that would help me understand 
>> this. First, I was wondering how the syscall provider obtains the 
>> arguments that correspond to arg0, arg1, ... argN, as I have been 
>> unable to locate this in the documentation, and also if it could be 
>> the case that a memory location referenced by a syscall argument could 
>> be manipulated between the time at which the entry and the return 
>> probes fire. Again, these are probably more OS implementation related 
>> questions than DTrace questions and may be inappropriate for this 
>> mailing list. Thank you very much for your time and patience,
>>    Michael Vaughn
>>
>>     
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>