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


David Smith wrote:
> Roland McGrath wrote:
>>> I feel positive I am missing something completely here!
>> Oh, wait.  We are talking about ia64.  So it probably actually can go
>> forward and backward in time.  We need to get the ia64 kernel people on
>> this, for sure.  I can see the potential rip in the fabric of spacetime,
>> but I don't really understand all the physics involved much at all.  The
>> corners of this might well differ in RHEL5 vs the vanilla ia64 kernel.
> 
> ... interesting technical discussion deleted ...
> 
> OK, you've convinced me.  I'll try to get access to an ia64 machine
> again and investigate further.

Here's an update.  After looking at this more, I decided the systemtap
internal code to get syscall arguments was too far off the upstream
code.  So, I copied the upstream code into systemtap (and have checked
this in).

The good news is that syscall arguments look much better in general now
and I don't see the all args as 0 problem.  The bad news is that the
utrace_syscall_args test still doesn't pass.

The new symptom is that whenever I use "syscall(number, args...)",
systemtap sees the syscall number as the 1st argument.  Here's an
example from a small test program I wrote:

  fd = dup(2);
  close(fd);
  fd = syscall (__NR_dup, 2);
  close(fd);

Logically, these calls should appear to systemtap as identical (as they
do to strace).  Here's what I get:

---------
# stap -ve 'probe process("duptest").syscall {printf("%d(0x%x, 0x%x,
0x%x)\n", $syscall, $arg1, $arg2, $arg3)}' -c ./duptest
...
1057(0x2, 0xff2cd8fe79459316, 0x60000fffff923750)
1029(0x3, 0xff2cd8fe79459316, 0x60000fffff923750)
1057(0x421, 0x2, 0x60000fffff923750)
1029(0x3, 0x2, 0x60000fffff923750)
1236(0x0, 0x3, 0x0)
Pass 5: run completed in 21usr/97sys/204real ms.
---------

On ia64, dup is 1057.  The first dup call above works correctly and sees
the 1st argument as 2.  The second dup call sees 0x421 as the 1st
argument (0x421 is 1057) and 2 as the 2nd argument.

The utrace_syscall_args test sees the same problem.  When syscall() is
used, the arguments are shifted over by 1.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)


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