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