Description of problem:
The default systemtap cannot find the "/lib/modules/$(uname -r)/bulid/vmlinux"!
The systemtap calls dwfl_linux_kernel_report_offline of elfutils, that cannot
find vmlinux file; I have straced it, it looked for vmlinux in the precedence:
# strace -e open stap -e '...'
it always failed to find the right position: "/lib/modules/$(uname -r)/build"!
As we all know, installing the vanilla linux kernel sources would setup a
symlink under "/lib/modules/$(uname -r)/" named "build" that links to the real
building directory, where the vmlinux file is always there, so if
dwfl_linux_kernel_report_offline function try this position
"/lib/modules/$(uname -r)/bulid/vmlinux", it would always find the vmlinux file.
by this we don't need to copy a vmlinux file to /boot/vmlinux or create a
/boot/vmlinux symlink to the real vmlinux file.
Version-Release number of selected component (if applicable):
non-redhat distro(gentoo here), with the vanilla kernel sources,
Steps to Reproduce:
1. unpack a vanilla kernel source;
2. make menuconfig && make && make modules_install && make install;
3. run stap -e '...', it cannot find vmlinux in the correct place.
it failed with:
Pass 1: parsed user script and 38 library script(s) in 280usr/20sys/439real ms.
semantic error: libdwfl failure (missing kernel 2.6.25 i686 debuginfo): No such
file or directory while resolving probe point kernel.function("sys_open")?
semantic error: no match while resolving probe point syscall.open
Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 embed(s), 0 global(s) in
Pass 2: analysis failed. Try again with more '-v' (verbose) options.
it should find vmlinux (with debuginfo) file in the correct place:
Created attachment 304312 [details]
add an entry "build" to DEFAULT_DEBUGINFO_PATH
Created attachment 304317 [details]
An alternative solution to this problem, this patch is to apply on top of systemtap.
dwfl_linux_kernel_report_offline function gets called twice in the systemtap
sources, and can accept a different debuginfo_path with the default in
Applying this to systemtap could also fix this problem, or just run stap with
SYSTEMTAP_DEBUGINFO_PATH=build stap -e '...'
could also resolve it, but I think the best solution is to fix it in the
library function, that could also benefit other programs using this libdw.so
library of elfutils package.
The library's default behavior looks in normal places for installed kernels. It
does not seem unreasonable to me that the default does not include some place
someone might have built their own kernel, just because you can guess such a
place. Where the default looks is where anyone using anything properly
installed would have it.
Your issue really is with systemtap usage, not with the library.
You can use the -r option to stap to point it at a particular directory I think.
If you can't that's a limitation for systemtap to fix. If you build your own
kernel and do not install it anywhere, running stap -r /lib/modules/`uname
-r`/build does not seem like a great burden.
(In reply to comment #3)
> The library's default behavior looks in normal places for installed kernels. It
> does not seem unreasonable to me that the default does not include some place
> someone might have built their own kernel, just because you can guess such a
> place. Where the default looks is where anyone using anything properly
> installed would have it.
But it is not real anyone, the anyone you said just means anyone using redhat
productions. You didn't account for linux systems from other distros, did you?
Your default value ":.debug:/usr/lib/debug" is just default from the redhat's
point of view; and now I just asked you add a feature from the kernel upstream,
not for any one distro; a default value "build" is from the kernel upstream,
your redhat's default didn't have such a path; so as a kernel related library
upstream, why not accept a default value from the kernel upstream?
> Your issue really is with systemtap usage, not with the library.
> You can use the -r option to stap to point it at a particular directory I think.
> If you can't that's a limitation for systemtap to fix. If you build your own
> kernel and do not install it anywhere, running stap -r /lib/modules/`uname
> -r`/build does not seem like a great burden.
It's really a great burden!
I know I can run systemtap without changes to the elfutils & systemtap sources;
using the "-r" argument or SYSTEMTAP_DEBUGINFO_PATH env value both can archive;
But do you think it's still really convenient that every time running stap with
Then he would give up, and follow your redhat standard:
# ln -s /lib/modules/$(uname -r)/build/vmlinux /boot/vmlinux-$(uname -r)
Instead, the upstream can do better for the end-user with a little modification
to the source.
Additionally, I'm intended that the problem should be fixed in the elfutils
library, just because it's a library function, next time I would write a program
using this library function, I could also benefit.
FWIW, I'm happy to apply the systemtap patch (though putting ":build" at the end
rather at the front), and IMO elfutils should consider adding this as a
tip-of-the-hat to the upstream default too. Finally, systemtap -r /BUILD-PATH/
will end up being supported at some point (bug #5892).
commit 12603f2 to systemtap git adds this feature.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
There is no rationale for changing the library function's behavior.