Re: Location of vmlinux debuginfo file

[Roland McGrath <roland at redhat dot com>]

The flexible solution where systemtap can specify the details of what it
wants more fully is something that comes naturally with the (coming) change
to use "offline" style (aka relocatability, aka cross-debugging).  There
systemtap can give an explicit directory name to elfutils (the function is
dwfl_linux_kernel_report_offline).  

/usr/lib/debug/boot/vmlinux-`uname -r` is already one of the files looked
for by default.  So I am not sure why there is a problem on SLES.
It first looks for /boot/vmlinux-`uname -r` and if that does exist then
it's used, and must either be the complete kernel with debuginfo itself,
or else have a corresponding file /usr/lib/debug/boot/vmlinux-`uname -r`.debug
(note the .debug suffix, /usr/lib/debug/PATH.debug is the standard
transformation for any PATH).  

What it does exactly is look first for /boot/vmlinux-REL, then looks for
/boot/vmlinux-REL in the path dirs (i.e. /usr/lib/debug/boot/vmlinux-REL),
then looks for /lib/modules/REL/vmlinux, then that in the path dirs.
Whichever of these four is found first is "the ELF file".  Then if the ELF
file itself does not contain DWARF info, we look for the corresponding
.debug file in the standard way as for any ELF file (same procedure is done
for each .ko, or each user executable and DSO), which means taking the file
name embedded in the .gnu.debuglink section (i.e. "BASENAME.debug", this is
chosen by the strip-to-file tools, eu-strip or binutils' strip/objcopy)
and looking for that in the debug path dirs (i.e. /usr/lib/debug).

When the file in /boot is actually a normal ELF file, as it is I think on
some machines and is for "kdump" kernels, then the completely vanilla
procedure is taking place matching up the ELF file /boot/vmlinux-REL with
its separate debuginfo file.  In other cases (most kernels), the hack I
just described is overloading the same debuginfo-path setting as a list of
places to look for likely vmlinux filenames as a special kludge for the kernel.


Thanks,
Roland