This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/18213] New: on arm, the runtime doesn't return correct syscall numbers
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Wed, 08 Apr 2015 17:00:47 +0000
- Subject: [Bug runtime/18213] New: on arm, the runtime doesn't return correct syscall numbers
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=18213
Bug ID: 18213
Summary: on arm, the runtime doesn't return correct syscall
numbers
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: runtime
Assignee: systemtap at sourceware dot org
Reporter: dsmith at redhat dot com
Host: arm
On arm (3.19.3-200.fc21.armv7hl), we're getting a large number of failures in
the syscall/nd_syscall tapset testsuite:
====
# of expected passes 66
# of unexpected failures 200
====
Lots of these are related to dwarfless-probe argument problems, but even in the
dwarf probe case the numbers are much worse than they should be.
After some debugging, I found out that the _stp_syscall_nr() tapset function
always returns 0, which breaks all use of the syscall gate macros (that prevent
syscall nesting). It appears that the kernel version of syscall_get_nr() always
returns 0 on arm.
--
You are receiving this mail because:
You are the assignee for the bug.