From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34052 invoked by alias); 30 Apr 2018 17:16:33 -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 33970 invoked by uid 48); 30 Apr 2018 17:16:28 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/22847] ARM OABI syscall tracing issues Date: Mon, 30 Apr 2018 17:16: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: dsmith at redhat 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-q2/txt/msg00045.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D22847 --- Comment #19 from David Smith --- (sorry for the delay in responding) (In reply to Gustavo Moreira from comment #18) > I ended up modifying the kernel to update thread_info struct with the > syscall number. Then I just call the original kernel syscall_get_nr() > function from SystemTap, which is working like a charm. Good deal. Have you tried getting the kernel patch upstream? ... stuff deleted ... > However, for instance, when it's used with your strace.stp which uses pro= be > alias, it doesn't work ... it doesn't report the syscalls. Even using an > EABI binary it doesn't report the syscalls. (See staprun_output_eabi.log = and > staprun_output_oabi.log) >=20 > I also noticed that, for instance from tapset/linux/sysc_connect.stp, > __syscall_gate() is called to filter the syscalls, so I've crafted some c= ode > (see syscalls_stpm.patch) to avoid to be filtered in case the syscall num= ber > doesn't match with the constants. >=20 > I'm not getting what is happening from the SystemTap side, it seems the > syscalls are being filtered somewhere ... could you please help me out? You'll need to break down the @__syscall_gate macro into smaller pieces and= see where it is calling "next". Another idea, perhaps simpler, would be to stick printf calls in that macro (and all that it calls) to let you know which ma= cro is calling "next". My guess would be that the @__syscall_gate_compat_simple macro is doing the filtering, but you'll need to test that theory. --=20 You are receiving this mail because: You are the assignee for the bug.