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:
> 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


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