From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121773 invoked by alias); 1 May 2018 02:46:26 -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 121683 invoked by uid 48); 1 May 2018 02:46:06 -0000 From: "gmoreira at gmail dot com" To: systemtap@sourceware.org Subject: [Bug runtime/22847] ARM OABI syscall tracing issues Date: Tue, 01 May 2018 02:46: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: gmoreira at gmail 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/msg00047.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D22847 --- Comment #20 from Gustavo Moreira --- (In reply to David Smith from comment #19) > (sorry for the delay in responding) >=20 > (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. >=20 > Good deal. Have you tried getting the kernel patch upstream? Not yet. Do you think they could be interested? >=20 > ... stuff deleted ... >=20 > > However, for instance, when it's used with your strace.stp which uses p= robe > > 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.lo= g 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= code > > (see syscalls_stpm.patch) to avoid to be filtered in case the syscall n= umber > > 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? >=20 > You'll need to break down the @__syscall_gate macro into smaller pieces a= nd > 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 macro is calling "next". My guess would be that the > @__syscall_gate_compat_simple macro is doing the filtering, but you'll ne= ed > to test that theory. Actually, the patches are fully working. The probes wasn't being called due= to the MAXSKIPPED limit: So, I've suppressed the time limits checks (--suppress-time-limits). I could also increase the limit to a specific value but anyway I wonder why it's happening now after these changes. What do you think about the changes in syscalls.stpm? Do they look good? It also shows two warnings in the output: WARNING: Skipped due to missed kretprobe/2 on 'kprobe.function("sys_readlink").return?': 1 WARNING: Skipped due to missed kprobe on 'kprobe.function("sys_readlink")?'= : 1 I don't think it would be important but anyway it would be nice if we could= fix it as well. Any clue? --=20 You are receiving this mail because: You are the assignee for the bug.