This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: systemtap fails to instrument kernel modules on ARM
- From: William Cohen <wcohen at redhat dot com>
- To: Da Zheng <zhengda1936 at gmail dot com>
- Cc: "systemtap at sourceware dot org" <systemtap at sourceware dot org>
- Date: Thu, 11 Aug 2011 15:32:02 -0400
- Subject: Re: systemtap fails to instrument kernel modules on ARM
- References: <4E44272C.9070902@gmail.com>
On 08/11/2011 03:02 PM, Da Zheng wrote:
> Hello,
>
> I tried to instrument the some function in the kernel module, but failed.
> I have a script called squashfs.stp:
> probe module("squashfs").function("squashfs_read_data") {
> printf("%s, squashfs_read_data: length: %d, srclength: %d, blocksize: %d\n",
> execname(), $length, $srclength, $sb->s_blocksize)
> }
>
> When I cross compile the script, I got the following error:
>
> $ stap --vp 01 -a arm -r /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard/ -p 4 -B CROSS_COMPILE=armv7a-cros-linux-gnueabi- -k squashfs.stp -m squashfs --all-modules
> semantic error: no match while resolving probe point module("squashfs").function("squashfs_read_data")
> Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0 global(s) using 51668virt/21632res/2132shr kb, in 0usr/40sys/36real ms.
> Pass 2: analysis failed. Try again with another '--vp 01' option.
>
> I see Cohen reported a bug of instrumenting a kernel module on ARM, but it seems the error message is a little bit different.
> I wonder if the error was caused because stap can't find the module, as all kernel modules aren't in the standard path and aren't in /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard/ either.
>
> Thanks,
> Da
Hi Da,
The instrumentation of kernel modules on arm doesn't work as mentioned in:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=13022
For the bz there is something going wrong in find_section() function. This might just be a different symptom of the same problem. Could you try running stap in gdb, and setting a breakpoint on __libdwfl_seterrno, Then just run your example and see if things are dying in find_section()? You will need elfutils debuginfo to set the breakpoint. Something like the following commands:
gdb stap
break __libdwfl_seterrno
run squashfs.stp
where
-Will