[Bug runtime/22847] ARM OABI syscall tracing issues

["mysecondaccountabc at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #5 from Gustavo Moreira <mysecondaccountabc at gmail dot com> ---
(In reply to David Smith from comment #4)
> > 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
> 

It's implemented using sys_connect:
...
Pass 5: starting run.
SyS_connect
Connected
Pass 5: run completed in 320usr/890sys/2179real ms

However, for some reason, the syscall probe alias syscall.*/nd_syscall.* don't
capture that.


> > 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
>  
The above returns:
SyS_connect - 32916

However, that is not correct because apparently _stp_syscall_nr() is made for
EABI where the syscall number is passed using R7.

systemtap/runtime/syscall.h:
...
#if defined(__arm__)
...
static inline long _stp_syscall_get_nr(struct task_struct *task, struct pt_regs
*regs)
{
        return regs->ARM_r7;
}

In OABI the syscall convention is svc 0x900000 + SYSCALL_NR.
For instance, for sys_exit() syscall:

EABI:
    mov r7, #0x01 ; sys_exit 
    svc #0x00 

OABI:
    svc #0x900001 ; sys_exit 

man syscall(2):
   arch/ABI   instruction          syscall #   retval Notes
   ──────────────────────────────────────────────────────────
   arm/OABI   swi NR               -           a1     NR is syscall #
   arm/EABI   swi 0x0              r7          r0

In the attached example:
$ objdump -d test_program  | grep -A2 "libc_connect>:"
00008830 <__libc_connect>:
    8830:       e92d4010        push    {r4, lr}
    8834:       ef90011b        svc     0x0090011b

Where 0x11b (283) is sys_connect .

In the kernel source
(https://elixir.bootlin.com/linux/v4.9.75/source/arch/arm/include/uapi/asm/unistd.h):
#define __NR_OABI_SYSCALL_BASE  0x900000
...
#if defined(__thumb__) || defined(__ARM_EABI__)
#define __NR_SYSCALL_BASE       0
#else
#define __NR_SYSCALL_BASE       __NR_OABI_SYSCALL_BASE
#endif
...
#define __NR_exit                       (__NR_SYSCALL_BASE+  1)
...
#define __NR_connect                    (__NR_SYSCALL_BASE+283)

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