4 ms·
What irks me the most is that in 2024, I still can't reliably embed source code in dwarf5 to get meaningful source-contextualized stacktraces and have to ship s
by Galanwe 2y ago
What irks me the most is that in 2024, I still can't reliably embed source code in dwarf5 to get meaningful source-contextualized stacktraces and have to ship source code separately and override the source mapping.
- forrestthewoods 2y agoStrong agree. At least on Windows you can setup Symbol Server + Source Indexing to achieve the same result. Once upon a time I wrote a small tool that can embed full source code into PDBs. I doubt anyone has ever used it though. For proprietary software it's not uncommon to leak PDBs on accident at some point. It could be disastrous to also leak full source code! https://www.forrestthewoods.com/blog/embedding-source-code-in-pdbs-with-rust/ https://www.forrestthewoods.com/blog/embedding-source-code-i... It's relatively easy to add source indexing to PDBs. I've successfully done that for a non-standard Monorepo. Works great.
- mark_undoio 2y agoThere'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 agoInteresting... 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.
- forrestthewoods 2y agoI don’t know why this isn’t more popular. Seems like PDB symbol server is more popular. At least in my circles.
- becurious 2y agoThere is SourceLink where you can get the mapping into the pdb files: https://github.com/dotnet/sourcelink https://github.com/dotnet/sourcelink