[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 #13 from Gustavo Moreira <gmoreira at gmail dot com> ---
(In reply to David Smith from comment #12)
> (In reply to Gustavo Moreira from comment #11)
> > (In reply to David Smith from comment #10)
> > > I wonder if we've got to handle both ABIs at once (more like a 32-bit ia32
> > > executable on a x86_64 kernel). Is CONFIG_OABI_COMPAT defined in your config
> > > file?
> > 
> > exactly, CONFIG_OABI_COMPAT=y. I think so, because when that is enabled the
> > kernel is able to execute both sort of ABI binaries.
> 
> OK, that makes more sense - I should have realized that earlier. Try the
> following patch (which tries to use the kernel's syscall_get_nr()) with
> *both* ABIs and see what syscall numbers you get:
> 
> ====
> diff --git a/runtime/syscall.h b/runtime/syscall.h
> index 5ed019869..2b551f16f 100644
> --- a/runtime/syscall.h
> +++ b/runtime/syscall.h
> @@ -169,7 +169,11 @@
>  static inline long
>  _stp_syscall_get_nr(struct task_struct *task, struct pt_regs *regs)
>  {
> +#ifdef CONFIG_OABI_COMPAT
> +	return syscall_get_nr(task, regs);
> +#else
>  	return regs->ARM_r7;
> +#endif
>  }
>  
>  #elif defined(__mips__)
> ====

I've just realised that the ARM machine also had systemtap-runtime and
systemtap-common 3.1-2 deb packages installed in /usr/share/systemtap, apart
from the /usr/local/share/systemtap installed from the systemtap-3.2 sources,
sorry by that.
Anyway, I'm back on the right track.

Without that patch, the results are
EABI:
 SyS_connect - 283
OABI:
 SyS_connect - 32916

With that patch:
EABI:
 SyS_connect - 0
OABI:
 SyS_connect - 0

So, that patch isn't working, it's always executing syscall_get_nr() which
seems to also return 0 always as the comment just above that code explains:

/* The syscall_get_nr() function on 3.17.1-302.fc21.armv7hl always
 * returns 0 (since it was designed to be used with ftrace syscall
 * tracing, not called from any context). So, let's use our function
 * instead. */

So, the first issue we have is that we are not correctly identifying the
appropriate constant to detect when it's in OABI compatibility mode.

I've tried all the following combinations but all of them are being executed in
both cases:
#if defined(__thumb__) || defined(__ARM_EABI__)
#if defined(CONFIG_OABI_COMPAT)
#if !defined(CONFIG_AEABI) || defined(CONFIG_OABI_COMPAT)
#if defined(__ARM_EABI__)

It should be a more dynamic way to detect that, I mean instead of using
preprocessor directives. Trying to see how the kernel differentiates those
modes, any thought?

On the other hand, once we can detect that we need to extract the syscall
number from the instruction itself. I have some ideas, trying to test if it
would work.

Anyway, having this done, what else you think it would be needed? Is that the
reason why the probe aliases are not catching for instance the sys_connect
trace point?

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