[Bug tapsets/11263] exposing foo32 syscalls

[dsmith at redhat dot com]

------- Additional Comments From dsmith at redhat dot com  2010-02-09 15:18 -------
On x86_64, the 64-bit pipe syscall (sys_pipe) has a syscall number of 22.  On
x86_64, the 32-bit pipe syscall (sys32_pipe) has a syscall number of 42.

unistd_32.h:#define __NR_pipe		 42
unistd_64.h:#define __NR_pipe				22

Admittedly, most of the 32-bit variants on x86_64 are just wrappers around the
64-bit functions (with some argument modification).  But, they are still
different system calls.

If you did a process.syscall probe looking for a '$syscall' of 22, you'll never
see it when executing a 32-bit exe that calls pipe().

Here's what I get when running systemtap against a small C program that opens a
pipe and closes it (compiled for both 64-bit and 32-bit):

# stap -ve 'probe syscall.* { printf("%s\n", probefunc()) }' -c pipe64
...
sys_pipe
sys_close
sys_close
sys_exit_group
do_exit
sys_wait4
sys_write

# stap -ve 'probe syscall.* { printf("%s\n", probefunc()) }' -c pipe32
...
sys32_pipe
sys_close
sys_close
sys_exit_group
do_exit
sys_wait4
sys_write

That output looks reasonable to me.  I'm confused as what the problem is here.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11263

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.