Bug 18213 - on arm, the runtime doesn't return correct syscall numbers
Summary: on arm, the runtime doesn't return correct syscall numbers
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: runtime (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-08 17:00 UTC by David Smith
Modified: 2015-04-08 17:03 UTC (History)
0 users

See Also:
Host: arm
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Smith 2015-04-08 17:00:47 UTC
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.
Comment 1 David Smith 2015-04-08 17:03:50 UTC
Fixed in commit 07cecda.

It appears that the arm kernel's syscall_get_nr() function is designed to only be used with ftrace syscall tracing. So, on arm, we'll use our own function.

With this patch, the number of syscall/nd_syscall passes almost doubles:

====
# of expected passes            129
# of unexpected failures        137
====