From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42924 invoked by alias); 19 Feb 2018 14:31:48 -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 42627 invoked by uid 48); 19 Feb 2018 14:31:38 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/22847] ARM OABI syscall tracing issues Date: Mon, 19 Feb 2018 14:31: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/msg00054.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D22847 --- Comment #8 from David Smith --- (In reply to Gustavo Moreira from comment #5) > (In reply to David Smith from comment #4) > > > 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 se= e what > > > gets hit. (If you need a test program, look in > > > testsuite/systemtap.syscall/connect.c.) > >=20 > > To be clear here, that try the following: > >=20 > > # stap -ve 'probe kernel.function("sys_connect").call, > > kernel.function("sys_socketcall").call { printf("%s\n", ppfunc()) }' -c > > test_program > >=20 >=20 > It's implemented using sys_connect: > ... > Pass 5: starting run. > SyS_connect > Connected > Pass 5: run completed in 320usr/890sys/2179real ms >=20 > However, for some reason, the syscall probe alias syscall.*/nd_syscall.* > don't capture that. >=20 >=20 > > > 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() r= eturns. > > > Is the number the same for both ABIs? > >=20 > > To be clear here, that try the following: > >=20 > > # stap -ve 'probe kernel.function("sys_connect").call, > > kernel.function("sys_socketcall").call { printf("%s - %d\n", ppfunc(), > > _stp_syscall_nr()) }' -c test_program > >=20=20 > The above returns: > SyS_connect - 32916 >=20 > However, that is not correct because apparently _stp_syscall_nr() is made > for EABI where the syscall number is passed using R7. >=20 > systemtap/runtime/syscall.h: > ... > #if defined(__arm__) > ... > static inline long _stp_syscall_get_nr(struct task_struct *task, struct > pt_regs *regs) > { > return regs->ARM_r7; > } >=20 > In OABI the syscall convention is svc 0x900000 + SYSCALL_NR. > For instance, for sys_exit() syscall: >=20 > EABI: > mov r7, #0x01 ; sys_exit=20 > svc #0x00=20 >=20 > OABI: > svc #0x900001 ; sys_exit=20 >=20 > man syscall(2): > arch/ABI instruction syscall # retval Notes > =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80 > arm/OABI swi NR - a1 NR is syscall # > arm/EABI swi 0x0 r7 r0 >=20 > In the attached example: > $ objdump -d test_program | grep -A2 "libc_connect>:" > 00008830 <__libc_connect>: > 8830: e92d4010 push {r4, lr} > 8834: ef90011b svc 0x0090011b >=20 > Where 0x11b (283) is sys_connect . >=20 > In the kernel source > (https://elixir.bootlin.com/linux/v4.9.75/source/arch/arm/include/uapi/as= m/ > unistd.h): > #define __NR_OABI_SYSCALL_BASE 0x900000 > ... > #if defined(__thumb__) || defined(__ARM_EABI__) > #define __NR_SYSCALL_BASE 0 > #else > #define __NR_SYSCALL_BASE __NR_OABI_SYSCALL_BASE > #endif > ... > #define __NR_exit (__NR_SYSCALL_BASE+ 1) > ... > #define __NR_connect (__NR_SYSCALL_BASE+283) OK, let's start small here and try to fix _stp_syscall_get_nr() for OABI. T= ry the following patch (which tries to use the kernel's syscall_get_nr()): =3D=3D=3D=3D diff --git a/runtime/syscall.h b/runtime/syscall.h index 5ed019869..1f5552d78 100644 --- a/runtime/syscall.h +++ b/runtime/syscall.h @@ -166,11 +166,15 @@ * returns 0 (since it was designed to be used with ftrace syscall * tracing, not called from any context). So, let's use our function * instead. */ +#if defined(__thumb__) || defined(__ARM_EABI__) static inline long _stp_syscall_get_nr(struct task_struct *task, struct pt_regs *regs) { return regs->ARM_r7; } +#else +#define _stp_syscall_get_nr syscall_get_nr +#endif #elif defined(__mips__) /* Define our own function as syscall_get_nr always returns 0 unless =3D=3D=3D=3D With that patch added, does the following return the correct value? # stap -ve 'kernel.function("sys_socketcall").call { printf("%s - %d\n", ppfunc(), _stp_syscall_nr()) }' -c test_program --=20 You are receiving this mail because: You are the assignee for the bug.