From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85147 invoked by alias); 22 Feb 2018 16:58:25 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 85044 invoked by uid 48); 22 Feb 2018 16:58:18 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/22847] ARM OABI syscall tracing issues Date: Thu, 22 Feb 2018 16:58:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: runtime X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dsmith at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2018-q1/txt/msg00060.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D22847 --- Comment #14 from David Smith --- (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-b= it ia32 > > > > executable on a x86_64 kernel). Is CONFIG_OABI_COMPAT defined in yo= ur config > > > > file? > > >=20 > > > exactly, CONFIG_OABI_COMPAT=3Dy. I think so, because when that is ena= bled the > > > kernel is able to execute both sort of ABI binaries. > >=20 > > 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: > >=20 > > =3D=3D=3D=3D > > 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 > > } > >=20=20 > > #elif defined(__mips__) > > =3D=3D=3D=3D >=20 > 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, ap= art > from the /usr/local/share/systemtap installed from the systemtap-3.2 > sources, sorry by that. > Anyway, I'm back on the right track. >=20 > Without that patch, the results are > EABI: > SyS_connect - 283 > OABI: > SyS_connect - 32916 >=20 > With that patch: > EABI: > SyS_connect - 0 > OABI: > SyS_connect - 0 >=20 > 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 explain= s: >=20 > /* 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 impr= oved since then. Unfortunately, I was wrong. For arm, the kernel seems to only s= ave 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. >=20 > I've tried all the following combinations but all of them are being execu= ted > 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__) >=20 > 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 kern= el 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 wa= y 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 case= s, 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 pr= oved 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. --=20 You are receiving this mail because: You are the assignee for the bug.