5 ms·

This brings up a question I have had, is it not possible to put the debug info in a separate file that gdb could load instead of in the binary itself? If you co

This brings up a question I have had, is it not possible to put the debug info in a separate file that gdb could load instead of in the binary itself? If you could do this, you could then easily have xyz-dbg packages that only contained these files, or even an distro repository of these files that the debugger could download as needed.

gtirloni 5y ago
Like this? https://access.redhat.com/solutions/9907 https://access.redhat.com/solutions/9907
10000truths 5y ago
Yes. You can separate the debug info from an object file with objcopy: objcopy --only-keep-debug foo.o foo.o.debug objcopy --strip-debug --add-gnu-debuglink=foo.o.debug foo.o And then link foo.o as normal. GDB should automatically be able to pick up the debug file by looking at the debug link. For more info, here's a link: https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Fil... You can also use gcc's -gsplit-dwarf command line option when compiling to produce a .dwo file containing your debug information: https://gcc.gnu.org/wiki/DebugFission https://gcc.gnu.org/wiki/DebugFission
- ceztko 5y ago
  I wanted to ask you if the "-gsplit-dwarf" is a 100% complete alternative to strip the symbols as done previously. I ask you because some modern projects[1] still prefer to compile with symbols and strip afterward. [1] https://github.com/dotnet/runtime/blob/main/eng/native/functions.cmake https://github.com/dotnet/runtime/blob/main/eng/native/funct...
stefan_ 5y ago
If you are in control of your build, ideally you want to embed build IDs and use a symbol server. Here is an older article from Bruce Dawson on this (unfortunately way underdeveloped) area of Linux: https://randomascii.wordpress.com/2013/02/20/symbols-on-linux-part-three-linux-versus-windows/ https://randomascii.wordpress.com/2013/02/20/symbols-on-linu...
AshamedCaptain 5y ago
This is exactly what most distributions do these days. The debug symbol packages are usually called -dbgsym (Ubuntu, Debian, ...) or -debuginfo (openSUSE, Fedora). This has been done automatically for almost a decade in most distros' packaging systems. GDB usually tells you what are the names of the debug packages you need to install for whatever you are trying to debug. The "distro repository of files that the debugger can download as needed" is called a debuginfod URL. E.g., for Debian : https://debuginfod.debian.net/ https://debuginfod.debian.net/ , openSUSE : https://debuginfod.opensuse.org/ https://debuginfod.opensuse.org/ , etc. This is a more recent development and distros are just starting to turn it on by default. But if enabled you'll basically see GDB start downloading symbol files automatically ala Windows when you run it. It even downloads the source code as it goes. Personally I think the latter is a security risk (since it sends to a server the hash/build-id of everything you try to debug), but I can't argue it's not convenient.

gtirloni 5y ago

Like this? https://access.redhat.com/solutions/9907 https://access.redhat.com/solutions/9907

10000truths 5y ago

Yes. You can separate the debug info from an object file with objcopy: objcopy --only-keep-debug foo.o foo.o.debug objcopy --strip-debug --add-gnu-debuglink=foo.o.debug foo.o And then link foo.o as normal. GDB should automatically be able to pick up the debug file by looking at the debug link. For more info, here's a link: https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Fil... You can also use gcc's -gsplit-dwarf command line option when compiling to produce a .dwo file containing your debug information: https://gcc.gnu.org/wiki/DebugFission https://gcc.gnu.org/wiki/DebugFission

ceztko 5y ago
I wanted to ask you if the "-gsplit-dwarf" is a 100% complete alternative to strip the symbols as done previously. I ask you because some modern projects[1] still prefer to compile with symbols and strip afterward. [1] https://github.com/dotnet/runtime/blob/main/eng/native/functions.cmake https://github.com/dotnet/runtime/blob/main/eng/native/funct...

stefan_ 5y ago

If you are in control of your build, ideally you want to embed build IDs and use a symbol server. Here is an older article from Bruce Dawson on this (unfortunately way underdeveloped) area of Linux: https://randomascii.wordpress.com/2013/02/20/symbols-on-linux-part-three-linux-versus-windows/ https://randomascii.wordpress.com/2013/02/20/symbols-on-linu...

AshamedCaptain 5y ago

This is exactly what most distributions do these days. The debug symbol packages are usually called -dbgsym (Ubuntu, Debian, ...) or -debuginfo (openSUSE, Fedora). This has been done automatically for almost a decade in most distros' packaging systems. GDB usually tells you what are the names of the debug packages you need to install for whatever you are trying to debug. The "distro repository of files that the debugger can download as needed" is called a debuginfod URL. E.g., for Debian : https://debuginfod.debian.net/ https://debuginfod.debian.net/ , openSUSE : https://debuginfod.opensuse.org/ https://debuginfod.opensuse.org/ , etc. This is a more recent development and distros are just starting to turn it on by default. But if enabled you'll basically see GDB start downloading symbol files automatically ala Windows when you run it. It even downloads the source code as it goes. Personally I think the latter is a security risk (since it sends to a server the hash/build-id of everything you try to debug), but I can't argue it's not convenient.