6 ms·
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? (
by 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 agoGDB 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.