This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/22847] ARM OABI syscall tracing issues
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Tue, 20 Feb 2018 16:03:22 +0000
- Subject: [Bug runtime/22847] ARM OABI syscall tracing issues
- Auto-submitted: auto-generated
- References: <bug-22847-6586@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=22847
--- Comment #12 from David Smith <dsmith at redhat dot com> ---
(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__)
====
--
You are receiving this mail because:
You are the assignee for the bug.