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 <mvau...@wisc.edu>
Date: Monday, June 1, 2009 11:57 am
Subject: garbled arguments with syscall provider.
To: dtrace-discuss@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@opensolaris.org
