[Bug runtime/22847] ARM OABI syscall tracing issues

[gmoreira at gmail dot com]

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

--- Comment #18 from Gustavo Moreira <gmoreira at gmail dot com> ---
I ended up modifying the kernel to update thread_info struct with the syscall
number. Then I just call the original kernel syscall_get_nr() function from
SystemTap, which is working like a charm.

# stap -v -g -p4 -m stap_abi_test -e probe kernel.function("sys_connect").call
{ printf("%s - 0x%x\n", ppfunc(), _stp_syscall_nr()) }

# staprun -c ../ex_socket_OABI ./stap_abi_test.ko
SyS_connect - 0x90011b
Connected

# staprun -c ../ex_socket_EABI ./stap_abi_test.ko
SyS_connect - 0x11b
Connected

However, for instance, when it's used with your strace.stp which uses probe
alias, it doesn't work ... it doesn't report the syscalls. Even using an EABI
binary it doesn't report the syscalls. (See staprun_output_eabi.log and
staprun_output_oabi.log)

I also noticed that, for instance from tapset/linux/sysc_connect.stp,
__syscall_gate() is called to filter the syscalls, so I've crafted some code
(see syscalls_stpm.patch) to avoid to be filtered in case the syscall number
doesn't match with the constants.

I'm not getting what is happening from the SystemTap side, it seems the
syscalls are being filtered somewhere ... could you please help me out?

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