This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Location of vmlinux debuginfo file
- From: Mike Mason <mmlnx at us dot ibm dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>, "Frank Ch. Eigler" <fche at redhat dot com>, SystemTAP <systemtap at sources dot redhat dot com>
- Date: Wed, 16 Aug 2006 13:36:49 -0700
- Subject: Re: Location of vmlinux debuginfo file
- References: <20060815005057.97D7C180051@magilla.sf.frob.com>
Roland McGrath wrote:
I was wrong in my original email. SLES puts vmlinux-`uname -r`.debug in
/usr/lib/debug/boot. If I create a link from that file to
/usr/lib/debug/boot/vmlinux-`uname -r` it works.
Ah. But there is no file called /boot/vmlinux-`uname -r`.
Yeah, I had the link direction backwards. Guess I shouldn't send email before I've been sufficiently caffeinated in the morning :-)
I'm not seeing where it ever tries to open a corresponding
/usr/lib/debug/boot/vmlinux-`uname -r`.debug file.
It doesn't. If /boot/vmlinux-`uname -r` existed and was an ELF file
containing a .gnu.debuglink section giving the name vmlinux-`uname -r`.debug,
then it would look for a /usr/lib/debug/boot/vmlinux-`uname -r`.debug file.
The standard debuginfo-finding behavior is based on starting with a
stripped ELF file that the debuginfo corresponds to. Given that there
isn't any such file for the kernel in many setups, it is certainly
reasonable to look for /usr/lib/debug/boot/vmlinux-`uname -r`.debug as a
special case (at least as reasonable as looking for
/usr/lib/debug/boot/vmlinux-`uname -r`).
OK, I think I'm starting to understand (slowly, sorry :-)). So in the case where we only have compressed vmlinu[zx] files in /boot and no /usr/lib/debug/lib/modules/`uname -r`/vmlinux (which is true for i386 and x86_64 in SLES 10) we need to open /usr/lib/debug/boot/vmlinux-`uname -r`.debug directly. On the other hand, if we have /boot/vmlinux-`uname -r` and a corresponding .debug file in /usr/lib/debug/boot (which is true on ppc64 in SLES 10), then opening /boot/vmlinux-`uname -r` is sufficient.
Would a patch like this be a suitable fix? It works for me.
diff -uNr elfutils-0.122.orig/libdwfl/linux-kernel-modules.c elfutils-0.122.new/libdwfl/linux-kern
el-modules.c
--- elfutils-0.122.orig/libdwfl/linux-kernel-modules.c 2006-04-13 08:04:57.000000000 -0700
+++ elfutils-0.122.new/libdwfl/linux-kernel-modules.c 2006-08-16 10:43:15.000000000 -0700
@@ -118,6 +118,13 @@
{
free (fname);
fname = NULL;
+ asprintf (&fname, "/boot/vmlinux-%s%s", release, ".debug");
+ fd = try_kernel_name (dwfl, &fname);
+ }
+ if (fd < 0 && release[0] != '/')
+ {
+ free (fname);
+ fname = NULL;
asprintf (&fname, MODULEDIRFMT "/vmlinux", release);
fd = try_kernel_name (dwfl, &fname);
}
Thanks,
Mike