This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Location of vmlinux debuginfo file

Roland McGrath wrote:
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

/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.

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.

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).

I'm not seeing where it ever tries to open a corresponding /usr/lib/debug/boot/vmlinux-`uname -r`.debug file. I put printf's next to every place an open is attempted and never saw an attempt to open that file. Had it attempted that, stap would have worked. I can see in dwfl_standard_find_debuginfo() where this might be possible if it's called with debuglink_file == NULL, but it doesn't appear to ever be called that way. What am I missing?

I also see various attempts to open files in a .debug subdirectory. Is that a standard place for debuginfo files?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]