[Bug runtime/22847] ARM OABI syscall tracing issues

["dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #14 from David Smith <dsmith at redhat dot com> ---
(In reply to Gustavo Moreira from comment #13)
> (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. */

Right. I had hoped that was just a 3.17 limitation and that things had improved
since then. Unfortunately, I was wrong. For arm, the kernel seems to only save
the syscall number when it knows the executable is being ptrace'd.

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

You've got 2 separate, but related, problems.

1) How do we determine if we've got an EABI or an OABI executable? The kernel
knows that if the argument to 'swi' is 0, we've got an EABI executable (see
arch/arm/kernel/entry-common.S). Otherwise, we've got an OABI executable.

2) Once we know what API the executable is using, how do we get the syscall
number? Once again the kernel knows this based on the argument to 'swi'.

Unfortunately, systemtap can't get the swi argument (at least not in any way I
can think of).

This situation is somewhat similar to running 32-bit executables on an x86_64
kernel (or 31-bit s390 executables on a 64-bit s390x kernel). In those cases,
we can test the TIF_32BIT thread flag to see which kind of executable we've
got. I don't see something similar here to test, although I'd love to be proved
wrong.

Your testing of the combinations of various CONFIG variables failed above
because this isn't a compile-time problem, this is a run-time problem.

I've been staring at arch/arm/kernel/entry-common.S, but I haven't had any
great ideas.

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