[Bug runtime/22847] ARM OABI syscall tracing issues

["dsmith at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22847

--- Comment #4 from David Smith <dsmith at redhat dot com> ---
(In reply to David Smith from comment #3)
> (In reply to Gustavo Moreira from comment #0)
> > The system is an ARMv7 (EABI) but the kernel is compiled with OABI
> > compatibility so that it can execute both ABI binaries. Everything is
> > working, both sort of binaries can be executed on it but SystemTap struggles
> > to trace the OABI syscalls. 
> > For instance, syscalls like "execve" and "exit" are traced but "connect" is
> > completely ignored. Most likely many other syscalls are ignored as well.
> 
> Let's take the example of the "connect" syscall. The connect() system call
> is complicated. On some systems, connect() is implemented via sys_connect().
> On other systems, it is implemented via sys_socketcall() (with $call set to
> SYS_CONNECT). Systemtap tries to catch the syscall on first entry to the
> kernel, and also tries to not give two probe hits on one actual syscall.
> 
> Doing this correctly is a bit complicated (see tapset/linux/sysc_connect.stp
> for all the details). One technique we use is rejecting the call to
> sys_connect() if the syscall number isn't __NR_connect. For your OABI
> binaries, it might be possible that you've got a different __NR_connect for
> each ABI or that systemtap isn't getting the syscall number correctly for
> that ABI.
> 
> You are going to have to debug this a bit to narrow it down. Some questions
> to try to answer:
> 
> 1) Is your connect syscall implemented via sys_connect() or through
> sys_socketcall(), or perhaps through some arch-specific function? Run a test
> binary, set a probe on both sys_connect() and sys_socketcall() and see what
> gets hit. (If you need a test program, look in
> testsuite/systemtap.syscall/connect.c.)

To be clear here, that try the following:

# stap -ve 'probe kernel.function("sys_connect").call,
kernel.function("sys_socketcall").call { printf("%s\n", ppfunc()) }' -c
test_program

> 2) Are you getting the correct syscall number for both ABIs? Run your test
> program (compiled once for each ABI) and see what _stp_syscall_nr() returns.
> Is the number the same for both ABIs?

To be clear here, that try the following:

# stap -ve 'probe kernel.function("sys_connect").call,
kernel.function("sys_socketcall").call { printf("%s - %d\n", ppfunc(),
_stp_syscall_nr()) }' -c test_program

> One more thing. The syscall testsuite should let you know exactly which
> syscalls are not working. To run the tests, do the following:
> 
> # make installcheck RUNTESTFLAGS="systemtap.syscall/*.exp"

I just realized the above really isn't going to help, since the testsuite won't
know that you've got that "extra" ABI and so won't compile for it. That
wouldn't be hard to change, but we'll have to come up with some way for the
testsuite to check for the ABI support.

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