From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55873 invoked by alias); 8 Apr 2015 17:00:51 -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 55815 invoked by uid 48); 8 Apr 2015 17:00:48 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/18213] New: on arm, the runtime doesn't return correct syscall numbers Date: Wed, 08 Apr 2015 17:00:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new 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: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cf_gcchost Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-q2/txt/msg00017.txt.bz2 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.