From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26346 invoked by alias); 15 Feb 2018 16:08:13 -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 26290 invoked by uid 48); 15 Feb 2018 16:08:08 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/22847] ARM OABI syscall tracing issues Date: Thu, 15 Feb 2018 16:08: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-q1/txt/msg00048.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D22847 --- Comment #4 from David Smith --- (In reply to David Smith from comment #3) > (In reply to Gustavo Moreira from comment #0) > > The system is an ARMv7 (EABI) but the kernel is compiled with OABI > > compatibility so that it can execute both ABI binaries. Everything is > > working, both sort of binaries can be executed on it but SystemTap stru= ggles > > to trace the OABI syscalls.=20 > > For instance, syscalls like "execve" and "exit" are traced but "connect= " is > > completely ignored. Most likely many other syscalls are ignored as well. >=20 > Let's take the example of the "connect" syscall. The connect() system call > is complicated. On some systems, connect() is implemented via sys_connect= (). > On other systems, it is implemented via sys_socketcall() (with $call set = to > SYS_CONNECT). Systemtap tries to catch the syscall on first entry to the > kernel, and also tries to not give two probe hits on one actual syscall. >=20 > Doing this correctly is a bit complicated (see tapset/linux/sysc_connect.= stp > for all the details). One technique we use is rejecting the call to > sys_connect() if the syscall number isn't __NR_connect. For your OABI > binaries, it might be possible that you've got a different __NR_connect f= or > each ABI or that systemtap isn't getting the syscall number correctly for > that ABI. >=20 > You are going to have to debug this a bit to narrow it down. Some questio= ns > to try to answer: >=20 > 1) Is your connect syscall implemented via sys_connect() or through > sys_socketcall(), or perhaps through some arch-specific function? Run a t= est > binary, set a probe on both sys_connect() and sys_socketcall() and see wh= at > gets hit. (If you need a test program, look in > testsuite/systemtap.syscall/connect.c.) To be clear here, that try the following: # stap -ve 'probe kernel.function("sys_connect").call, kernel.function("sys_socketcall").call { printf("%s\n", ppfunc()) }' -c test_program > 2) Are you getting the correct syscall number for both ABIs? Run your test > program (compiled once for each ABI) and see what _stp_syscall_nr() retur= ns. > Is the number the same for both ABIs? To be clear here, that try the following: # stap -ve 'probe kernel.function("sys_connect").call, kernel.function("sys_socketcall").call { printf("%s - %d\n", ppfunc(), _stp_syscall_nr()) }' -c test_program > One more thing. The syscall testsuite should let you know exactly which > syscalls are not working. To run the tests, do the following: >=20 > # make installcheck RUNTESTFLAGS=3D"systemtap.syscall/*.exp" I just realized the above really isn't going to help, since the testsuite w= on't know that you've got that "extra" ABI and so won't compile for it. That wouldn't be hard to change, but we'll have to come up with some way for the testsuite to check for the ABI support. --=20 You are receiving this mail because: You are the assignee for the bug.