From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93994 invoked by alias); 19 Feb 2018 22:42:06 -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 93244 invoked by uid 48); 19 Feb 2018 22:42:00 -0000 From: "mysecondaccountabc at gmail dot com" To: systemtap@sourceware.org Subject: [Bug runtime/22847] ARM OABI syscall tracing issues Date: Mon, 19 Feb 2018 22:42: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/msg00055.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D22847 --- Comment #9 from Gustavo Moreira -= -- (In reply to David Smith from comment #8) > (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? R= un 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 > >=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 yo= ur test > > > > program (compiled once for each ABI) and see what _stp_syscall_nr()= returns. > > > > 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 ma= de > > 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/= 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 > OK, let's start small here and try to fix _stp_syscall_get_nr() for OABI. > Try the following patch (which tries to use the kernel's syscall_get_nr()= ): >=20 > =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 >=20=20 > #elif defined(__mips__) > /* Define our own function as syscall_get_nr always returns 0 unless > =3D=3D=3D=3D >=20 > With that patch added, does the following return the correct value? >=20 > # stap -ve 'kernel.function("sys_socketcall").call { printf("%s - %d\n", > ppfunc(), _stp_syscall_nr()) }' -c test_program I've added "probe" at the beginning and changed the syscall to "sys_connect" because it doesn't use sys_socketcall.=20 # stap -ve 'probe kernel.function("sys_connect").call { printf("%s - %d\n", ppfunc(), _stp_syscall_nr()) }' -c ./ex_socket_OABI=20 Pass 1: parsed user script and 452 library scripts using 40896virt/33624res/4948shr/28920data kb, in 4780usr/1090sys/5869real ms. Pass 2: analyzed script: 1 probe, 2 functions, 97 embeds, 0 globals using 77520virt/70912res/5528shr/65544data kb, in 13480usr/11970sys/25472real ms. Pass 3: translated to C into "/tmp/stapSl5Rx9/stap_195c43dcde9908a38abbe97ece0f593b_53976_src.c" using 77520virt/71040res/5656shr/65544data kb, in 1670usr/10930sys/12604real ms. Pass 4: compiled C into "stap_195c43dcde9908a38abbe97ece0f593b_53976.ko" in 58570usr/20570sys/73572real ms. Pass 5: starting run. SyS_connect - 32916 Connected Pass 5: run completed in 370usr/1000sys/2316real ms. However, the result seems to be the same. I've patched the file in the installation directory (/usr/share/systemtap/runtime/syscall.h). I don't th= ink SystemTap needs to be completely recompiled again, right? The change should= be included when it compiles the LKM in the above stap execution. --=20 You are receiving this mail because: You are the assignee for the bug.