3 ms·

There's `debuginfod` on Linux: https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-elfutils-debuginfo-server https://developers.redhat.com/

There's `debuginfod` on Linux: https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-elfutils-debuginfo-server https://developers.redhat.com/blog/2019/10/14/introducing-de... It builds a lot on quite a simple conceptual base, benefiting from native support in gcc / clang (for embedding unique build IDs) and in GDB (for contacting the server). It can serve up both source and symbol information. I would like to see this adopted more - e.g. build infrastructure automatically populating a debuginfod server so debugging is seamless.

trentnelson 2y ago
Interesting... I've been lamenting the absence of .pdbs on Linux. It sounds like this would allow dissasociating symbol info from the build artifact itself? (There's no other out-of-the-box solution to this right? i.e. having symbol info live somewhere else other than the .so/exe, that can be loaded on demand when debugging? Like .pdbs basically.)
- mark_undoio 2y ago
  GDB is happy to deal with separate debug info files from the executable code - and has been approximately "always", as far as I'm aware. But it's not particularly common / well-understood how to actually achieve it. Some info here on how to configure GDB to use it: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Separate-Debug-Files.html https://sourceware.org/gdb/current/onlinedocs/gdb.html/Separ... The old-school way appears to be to extract the debug information from the binaries after compilation, then strip the binaries. As described here: https://stackoverflow.com/questions/866721/how-to-generate-gcc-debug-symbol-outside-the-build-target https://stackoverflow.com/questions/866721/how-to-generate-g... The new way is to use gcc's ability to generate split DWARF directly: https://interrupt.memfault.com/blog/dealing-with-large-symbol-files#splitting-debug-info-at-build-time https://interrupt.memfault.com/blog/dealing-with-large-symbo... This will work with debuginfod but you don't have to have that running to use these - you can just supply the symbol directory when you want to debug.
forrestthewoods 2y ago
I don’t know why this isn’t more popular. Seems like PDB symbol server is more popular. At least in my circles.

trentnelson 2y ago

Interesting... I've been lamenting the absence of .pdbs on Linux. It sounds like this would allow dissasociating symbol info from the build artifact itself? (There's no other out-of-the-box solution to this right? i.e. having symbol info live somewhere else other than the .so/exe, that can be loaded on demand when debugging? Like .pdbs basically.)

mark_undoio 2y ago
GDB is happy to deal with separate debug info files from the executable code - and has been approximately "always", as far as I'm aware. But it's not particularly common / well-understood how to actually achieve it. Some info here on how to configure GDB to use it: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Separate-Debug-Files.html https://sourceware.org/gdb/current/onlinedocs/gdb.html/Separ... The old-school way appears to be to extract the debug information from the binaries after compilation, then strip the binaries. As described here: https://stackoverflow.com/questions/866721/how-to-generate-gcc-debug-symbol-outside-the-build-target https://stackoverflow.com/questions/866721/how-to-generate-g... The new way is to use gcc's ability to generate split DWARF directly: https://interrupt.memfault.com/blog/dealing-with-large-symbol-files#splitting-debug-info-at-build-time https://interrupt.memfault.com/blog/dealing-with-large-symbo... This will work with debuginfod but you don't have to have that running to use these - you can just supply the symbol directory when you want to debug.

forrestthewoods 2y ago

I don’t know why this isn’t more popular. Seems like PDB symbol server is more popular. At least in my circles.