This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: systemtap fails to instrument kernel modules on ARM


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]