[Bug runtime/22847] ARM OABI syscall tracing issues

["gmoreira at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #20 from Gustavo Moreira <gmoreira at gmail dot com> ---
(In reply to David Smith from comment #19)
> (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?


Not yet. Do you think they could be interested?

> 
> ... 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.

Actually, the patches are fully working. The probes wasn't being called due to
the MAXSKIPPED limit:
So, I've suppressed the time limits checks (--suppress-time-limits). I could
also increase the limit to a specific value but anyway I wonder why it's
happening now after these changes.

What do you think about the changes in syscalls.stpm? Do they look good?

It also shows two warnings in the output:

WARNING: Skipped due to missed kretprobe/2 on
'kprobe.function("sys_readlink").return?': 1
WARNING: Skipped due to missed kprobe on 'kprobe.function("sys_readlink")?': 1

I don't think it would be important but anyway it would be nice if we could fix
it as well. Any clue?

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