[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

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com

--- Comment #3 from David Smith <dsmith at redhat dot com> ---
(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.)

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?

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"

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