This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: utrace syscall arguments


> Actually, I meant both.  If the syscall fails or if I use a bogus
> syscall number, the args all came back as 0.  

You mean "had come back", right?  That is, arguments as seen at the entry
tracing stop before success or failure has even come into being.  This is
very hard to grok.  If you trace open("/",O_WRONLY), entry tracing does not
see the right arguments because the kernel has looked into the future and
divined that you won't have permission on the filesystem when the call is
tried?  But what could possibly be different at entry from when you trace
open("/",O_RDONLY) and the call will then have been going to succeed?  If
you see the arguments at entry tracing and use syscall_set_arguments() to
change the second argument to O_WRONLY and then resume, does the kernel go
back in time to have failed to give you those arguments in the first place?
(And if so, does that make you your own grandpa?)

I feel positive I am missing something completely here!


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]