This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/22847] ARM OABI syscall tracing issues
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Mon, 19 Feb 2018 22:53:53 +0000
- Subject: [Bug runtime/22847] ARM OABI syscall tracing issues
- Auto-submitted: auto-generated
- References: <bug-22847-6586@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=22847
--- Comment #10 from David Smith <dsmith at redhat dot com> ---
(In reply to Gustavo Moreira from comment #9)
> > 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
>
> I've added "probe" at the beginning and changed the syscall to "sys_connect"
> because it doesn't use sys_socketcall.
Sorry, I misremembered how your kernel worked.
> # stap -ve 'probe kernel.function("sys_connect").call { printf("%s - %d\n",
> ppfunc(), _stp_syscall_nr()) }' -c ./ex_socket_OABI
> 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
> think SystemTap needs to be completely recompiled again, right? The change
> should be included when it compiles the LKM in the above stap execution.
Right. Hmm.
I wonder if we've got to handle both ABIs at once (more like a 32-bit ia32
executable on a x86_64 kernel). Is CONFIG_OABI_COMPAT defined in your config
file?
--
You are receiving this mail because:
You are the assignee for the bug.