[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 #19 from David Smith <dsmith at redhat dot com> ---
(sorry for the delay in responding)

(In reply to Gustavo Moreira from comment #18)
> 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.

Good deal. Have you tried getting the kernel patch upstream?

... stuff deleted ...

> 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'll need to break down the @__syscall_gate macro into smaller pieces and see
where it is calling "next". Another idea, perhaps simpler, would be to stick
printf calls in that macro (and all that it calls) to let you know which macro
is calling "next". My guess would be that the @__syscall_gate_compat_simple
macro is doing the filtering, but you'll need to test that theory.

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