From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81571 invoked by alias); 15 Feb 2018 15:45:46 -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 81261 invoked by uid 48); 15 Feb 2018 15:45:35 -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 15:45: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: cc 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/msg00047.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D22847 David Smith changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dsmith at redhat dot com --- Comment #3 from David Smith --- (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 strugg= les > 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. 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. 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 binar= ies, it might be possible that you've got a different __NR_connect for each ABI = or that systemtap isn't getting the syscall number correctly for that ABI. You are going to have to debug this a bit to narrow it down. Some questions= to try to answer: 1) Is your connect syscall implemented via sys_connect() or through sys_socketcall(), or perhaps through some arch-specific function? Run a test binary, set a probe on both sys_connect() and sys_socketcall() and see what gets hit. (If you need a test program, look in testsuite/systemtap.syscall/connect.c.) 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() returns= . Is the number the same for both ABIs? One more thing. The syscall testsuite should let you know exactly which syscalls are not working. To run the tests, do the following: # make installcheck RUNTESTFLAGS=3D"systemtap.syscall/*.exp" --=20 You are receiving this mail because: You are the assignee for the bug.