This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: error to run systemtap in an ARM platform
On Sat, 2011-07-23 at 15:55 -0700, Zheng Da wrote:
> Hello,
>
> I'm still trying to fix the problem.
> semantic error: failed to retrieve return value location for vfs_write
> (/build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/fs/read_write.c):
> identifier '$return' at read-write.stp:7:6
> source: if ($return > 0) {
> ^
Is this the only probe for which return values aren't available or are
there others? What is your full script for triggering this issue?
> I'm pretty sure CONFIG_DEBUG_INFO is enabled, and in
> /build/tegra2_seaboard/tmp/portage/sys-kernel/chromeos-kernel-9999/work/chromeos-kernel-9999/build/tegra2_seaboard,
> a binary file vmlinux is 57MB. It should contain the debug information.
Would you be able to upload this somewhere so we can inspect the debug
information? This looks like it is just the kernel image, not the
debuginfo, which is often bigger. You can see with stap -vvv what
systemtap is using. e.g.:
focused on module 'kernel' = [0x0xffffffff81000000,
-0x0xffffffff81e64000, bias 0x0
file /usr/lib/debug/lib/modules/2.6.35.13-92.fc14.x86_64/vmlinux ELF
machine |x86_64 (code 62)
> How does systemtap use the debug information? When it compiles the
> script, does it need to read the debug information from the kernel
> image? or it needs to read the .obj files of the kernel?
It processes the debug information (either in the vmlinux image itself
or from a separate debuginfo file) to extract knowledge of where to find
probe points, parameters, variables, return values and types. This is
used during the translate pass to produce the stap module. So that it
isn't necessary at runtime of the module (for this of course the
version/arch of the debuginfo during translate time and the linux kernel
at runtime should match).
Cheers,
Mark