Bug 444886
| Summary: | make dwfl_linux_kernel_report_offline function (from libdwfl/linux-kernel-modules.c) aware of "/lib/modules/$(uname -r)/bulid/vmlinux" | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | rae <crquan> | ||||||
| Component: | elfutils | Assignee: | Frank Ch. Eigler <fche> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | low | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 9 | CC: | roland, wcohen | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-08-14 10:09:23 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
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
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.
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 "-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. 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping There is no rationale for changing the library function's behavior. |
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.