From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89048 invoked by alias); 16 Feb 2018 04:06:35 -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 88347 invoked by uid 48); 16 Feb 2018 04:06:30 -0000 From: "mysecondaccountabc at gmail dot com" To: systemtap@sourceware.org Subject: [Bug runtime/22847] ARM OABI syscall tracing issues Date: Fri, 16 Feb 2018 04:06: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: mysecondaccountabc 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-q1/txt/msg00049.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D22847 --- Comment #5 from Gustavo Moreira -= -- (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 see = 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 It's implemented using sys_connect: ... Pass 5: starting run. SyS_connect Connected Pass 5: run completed in 320usr/890sys/2179real ms However, for some reason, the syscall probe alias syscall.*/nd_syscall.* do= n't capture that. > > 2) Are you getting the correct syscall number for both ABIs? Run your t= est > > program (compiled once for each ABI) and see what _stp_syscall_nr() ret= urns. > > 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 However, that is not correct because apparently _stp_syscall_nr() is made f= or EABI where the syscall number is passed using R7. 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; } In OABI the syscall convention is svc 0x900000 + SYSCALL_NR. For instance, for sys_exit() syscall: EABI: mov r7, #0x01 ; sys_exit=20 svc #0x00=20 OABI: svc #0x900001 ; sys_exit=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 In the attached example: $ objdump -d test_program | grep -A2 "libc_connect>:" 00008830 <__libc_connect>: 8830: e92d4010 push {r4, lr} 8834: ef90011b svc 0x0090011b Where 0x11b (283) is sys_connect . In the kernel source (https://elixir.bootlin.com/linux/v4.9.75/source/arch/arm/include/uapi/asm/= 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) --=20 You are receiving this mail because: You are the assignee for the bug.