This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: utrace syscall arguments
David Smith wrote:
> 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.
AFAICS in glibc, sysdeps/unix/sysv/linux/ia64/syscall.S
uses alloc to shift arguments (skips 1st argument) as below.
---
ENTRY(syscall)
alloc r2=ar.pfs,1,0,8,0
mov r15=r32 /* syscall number */
break __BREAK_SYSCALL
;;
---
This frame will be used when calling syscall handlers,
and it will be saved in cr_ifs.
So, I guess it is possible that we can check the system
call is syscall or not by checking cr_ifs.
Thanks,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com