I can''t get a combined source/disassembly listing from objdump using the kernel-debuginfo package: 1) objdump has no clue how to use the separate debug info: http://sourceware.org/bugzilla/show_bug.cgi?id=4030 No activity, bug is unassigned. 2) The path to the debug info is wrong anyway. In fact, there _is_ no path info in the .gnu_debuglink section of the kernel modules: $ objdump -j .gnu_debuglink -D ahci.ko ahci.ko: file format elf32-i386 Disassembly of section .gnu_debuglink: 00000000 <.gnu_debuglink>: 0: 61 popa 1: 68 63 69 2e 6b push $0x6b2e6963 6: 6f outsl %ds:(%esi),(%dx) 7: 2e 64 65 62 75 67 bound %esi,%cs:%fs:%gs:0x67(%ebp) d: 00 00 add %al,(%eax) f: 00 21 add %ah,(%ecx) 11: 25 .byte 0x25 12: 80 .byte 0x80 13: c9 leave This decodes to "ahci.ko.debug" plus a checksum, but it should read "/usr/lib/debug/lib/modules/2.6.20-1.2925.fc6/kernel/drivers/ata/ahci.ko.debug" So my question is, who uses this debug info and how do they use it???
> 2) The path to the debug info is wrong anyway. In fact, there _is_ > no path info in the .gnu_debuglink section of the kernel modules:They''re not supposed to have directory names. Try elfutils tools, or gdb. They handle separate debuginfo well. e.g. eu-addr2line -k 0x... is nice. We don''t yet have disassembly tools in elfutils, unfortunately. gdb will deal well with a .ko and find its debug info, and has disassembly and source info. It doesn''t have an interleaved output format AFAIK, though. I''ve considered writing an "unstrip" to paste stripped and .debug file back together so you can use them with dumber tools.
Roland McGrath wrote:>> 2) The path to the debug info is wrong anyway. In fact, there _is_ >> no path info in the .gnu_debuglink section of the kernel modules: > > They''re not supposed to have directory names. Try elfutils tools, or gdb. > They handle separate debuginfo well. e.g. eu-addr2line -k 0x... is nice. > We don''t yet have disassembly tools in elfutils, unfortunately.Well, addr2line works because you point it directly to the .ko.debug file: $ eu-addr2line -e ahci.ko.debug 0x0 drivers/ata/ahci.c:479> > gdb will deal well with a .ko and find its debug info, and has disassembly > and source info. It doesn''t have an interleaved output format AFAIK, though. >But how could gdb put the two separate files together when there is no connection between them? How could it possibly know to go from: /lib/modules/2.6.20-1.2925.fc6/kernel/drivers/ata/ahci.ko to /usr/lib/debug/lib/modules/2.6.20-1.2925.fc6/kernel/drivers/ata/ahci.ko.debug without the full path name in the .gnu_debuglink section of the module? The debug info file does have the full (and correct) pathname of the source: comp_dir "/usr/src/debug/kernel-2.6.20/linux-2.6.20.i686" This still isn''t quite right; it should really be: "/usr/src/debug/kernel-2.6.20/linux-2.6.20-1.2925.i686" But that is really where the installer puts the files, so it''s just a minor packaging problem. (You can only have one 2.6.20 kernel source tree installed for debugging using the current naming convention.)> I''ve considered writing an "unstrip" to paste stripped and .debug file back > together so you can use them with dumber tools. >Yeah, that would be nice.
> Well, addr2line works because you point it directly to the .ko.debug file: > > $ eu-addr2line -e ahci.ko.debug 0x0 > drivers/ata/ahci.c:479That does not necessarily work, because it may not be able to do enough relocation. -e /installed/stripped/file, -k, -K, -p PID work, and they find the debuginfo file for you. (For ET_REL files you need to add 0x10000 to the address you use if using elfutils < 0.126.)> But how could gdb put the two separate files together when there is no > connection between them? How could it possibly know to go from: > > /lib/modules/2.6.20-1.2925.fc6/kernel/drivers/ata/ahci.ko > > to > > /usr/lib/debug/lib/modules/2.6.20-1.2925.fc6/kernel/drivers/ata/ahci.ko.debugLo and behold, it does work. Really, truly. Embedding directory names is Not The Way. (Try "help set debug-file-directory" in gdb. The elfutils tools and their --debuginfo-path option are similar.)
Roland McGrath wrote:> (Try "help set debug-file-directory" in gdb. The elfutils > tools and their --debuginfo-path option are similar.) >That''s the missing piece. Thanks. But still, I have to do a --debuginfo-path that''s different for each module. e.g. for ata modules it''s <...>/drivers/ata/ and for crypto it''s <...>/crypto/. Shouldn''t the final part of the path be in the .gnu_debuginfo?
> Roland McGrath wrote: > > (Try "help set debug-file-directory" in gdb. The elfutils > > tools and their --debuginfo-path option are similar.) > > That''s the missing piece. Thanks. > > But still, I have to do a --debuginfo-path that''s different for > each module. e.g. for ata modules it''s <...>/drivers/ata/ and > for crypto it''s <...>/crypto/. Shouldn''t the final part of the > path be in the .gnu_debuginfo?No. Sorry, I was unclear on the exact meaning. From a libdwfl.h comment: If the first character of the string is + or - that says to check or to ignore (respectively) the CRC32 checksum from the .gnu_debuglink section. The default is to check it. The remainder of the string is composed of elements separated by colons. Each element can start with + or - to override the global checksum behavior. If the remainder of the element is empty, the directory containing the main file is tried; if it''s an absolute path name, the absolute directory path containing the main file is taken as a subdirectory of this path; a relative path name is taken as a subdirectory of the directory containing the main file. Hence for /bin/ls, string ":.debug:/usr/lib/debug" says to look in /bin, then /bin/.debug, then /usr/lib/debug/bin, for the file name in the .gnu_debuglink section (or "ls.debug" if none was found). */