From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73930 invoked by alias); 22 Feb 2018 00:04:29 -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 73895 invoked by uid 48); 22 Feb 2018 00:04:23 -0000 From: "gmoreira at gmail dot com" To: systemtap@sourceware.org Subject: [Bug runtime/22847] ARM OABI syscall tracing issues Date: Thu, 22 Feb 2018 00:04: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: gmoreira at gmail 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/msg00059.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D22847 --- Comment #13 from Gustavo Moreira --- (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? > >=20 > > exactly, CONFIG_OABI_COMPAT=3Dy. I think so, because when that is enabl= ed 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 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 source= s, 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 execute= d 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 t= he reason why the probe aliases are not catching for instance the sys_connect trace point? --=20 You are receiving this mail because: You are the assignee for the bug.