Bug 444886 - make dwfl_linux_kernel_report_offline function (from libdwfl/linux-kernel-modules.c) aware of "/lib/modules/$(uname -r)/bulid/vmlinux"
make dwfl_linux_kernel_report_offline function (from libdwfl/linux-kernel-mod...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: elfutils (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Frank Ch. Eigler
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-01 11:37 EDT by rae
Modified: 2008-08-14 06:09 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-14 06:09:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
add an entry "build" to DEFAULT_DEBUGINFO_PATH (460 bytes, patch)
2008-05-01 11:37 EDT, rae
no flags Details | Diff
An alternative solution to this problem, this patch is to apply on top of systemtap. (1.03 KB, patch)
2008-05-01 12:00 EDT, rae
no flags Details | Diff

  None (edit)
Description rae 2008-05-01 11:37:26 EDT
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 '...'
...
/boot/vmlinux-2.6.25
/boot/vmlinux-2.6.25
/boot/.debug/vmlinux-2.6.25
/usr/lib/debug/boot/vmlinux-2.6.25
/boot/vmlinux-2.6.25.debug
/boot/.debug/vmlinux-2.6.25.debug
/usr/lib/debug/boot/vmlinux-2.6.25.debug
/lib/modules/2.6.25/vmlinux
/lib/modules/2.6.25/vmlinux
/lib/modules/2.6.25/.debug/vmlinux
/usr/lib/debug/lib/modules/2.6.25/vmlinux
/lib/modules/2.6.25/vmlinux.debug
/lib/modules/2.6.25/.debug/vmlinux.debug
/usr/lib/debug/lib/modules/2.6.25/vmlinux.debug

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,

How reproducible:

Always.

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.

Actual results:

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
10usr/0sys/8real ms.
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.


Expected results:

it should find vmlinux (with debuginfo) file in the correct place:
"/lib/modules/$(uname -r)/build"

Additional info:

none.
Comment 1 rae 2008-05-01 11:37:26 EDT
Created attachment 304312 [details]
add an entry "build" to DEFAULT_DEBUGINFO_PATH
Comment 2 rae 2008-05-01 12:00:04 EDT
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
elfutils;

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.
Comment 3 Roland McGrath 2008-05-05 19:15:16 EDT
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.
Comment 4 rae 2008-05-05 21:39:56 EDT
(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
"-r" argument?

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.

Comment 5 Frank Ch. Eigler 2008-05-05 22:33:43 EDT
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).
Comment 6 Frank Ch. Eigler 2008-05-05 22:53:45 EDT
commit 12603f2 to systemtap git adds this feature.
Comment 7 Bug Zapper 2008-05-14 06:28:43 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Roland McGrath 2008-08-14 06:09:23 EDT
There is no rationale for changing the library function's behavior.

Note You need to log in before you can comment on or make changes to this bug.