GDB Kernel Dump: Find the executable using the build-id

Question

Is it possible that gdb will automatically find the appropriate executable? I extracted the debug symbols and put them in the /usr/lib/debug/.build-id/ directory. When I start gdb with gdb /usr/bin/executable core , everything works fine. All debugging symbols for the executable and all shared libraries are automatically loaded because gdb knows about build-id and automatically loads it.

 $ gdb /usr/bin/executable core GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/executable...Reading symbols from /usr/lib/debug/.build-id/b7/fada8ba917de74a6055647f3ac205dee1615c8.debug...done. 

However, when I just run gdb and load the kernel file, no debug symbols are loaded.

 (gdb) core-file core [New Thread 10822] [New Thread 10812] Core was generated by `/usr/bin/executable'. Program terminated with signal 6, Aborted. #0 0xb7790424 in __kernel_vsyscall () 

Running gdb with strace shows that it is not even trying to find them. The main file contains build-id, so I think gdb should find it ...

 $ eu-unstrip -n --core core 0x8048000+0x25d000 b7fada8ba917de74a6055647f3ac205dee1615c8@0x8048178 - - [exe] 0xb7790000+0x1000 da7bd9bbfe599f7e9b644d684db983c4b34d8f31@0xb77901ec . - linux-gate.so.1 0xb7771000+0x19000 242ae1f2965ed161f3715858d7792019963b57fd@0xb7771164 /lib/i686/cmov/libpthread.so.0 - libpthread.so.0 0xb7768000+0x9000 06a49519b1ede0f79596e4b0cd07d2beba43b2dc@0xb7768164 /lib/i686/cmov/librt.so.1 - librt.so.1 0xb7672000+0xf5000 9daf5aac9ccc9281f2805639c3f87731beae5548@0xb7672144 /usr/lib/libstdc++.so.6 - libstdc++.so.6 0xb764c000+0x26000 696d5fb148fe51609203903d470a8f85d458cd17@0xb764c164 /lib/i686/cmov/libm.so.6 - libm.so.6 0xb762e000+0x1e000 d2a7edbd5dafabb7bb90198eeb58013342c589f0@0xb762e104 /lib/libgcc_s.so.1 - libgcc_s.so.1 0xb74e7000+0x147000 2124040143ac9f7478cc16b474b1cfdfe2c45353@0xb74e7184 /lib/i686/cmov/libc.so.6 - libc.so.6 0xb7791000+0x1d000 5a6fc3cf12f68887cbf22da3a9785d00f7d91c41@0xb7791124 /lib/ld-linux.so.2 - ld-linux.so.2 

Is there a way to get gdb to look for debug files for the executable without providing the executable that caused the kernel dump?

Answer 1

You can try loading debug symbols directly:

 (gdb) symbol-file /tmp/your_debug_symbols.dbg 

But I do not think that the coredump kernel itself is enough for GDB, the executable should be provided to understand the kernel dump.