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.
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-i...
It's relatively easy to add source indexing to PDBs. I've successfully done that for a non-standard Monorepo. Works great.
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.
(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.)
Some info here on how to configure GDB to use it: 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-g...
The new way is to use gcc's ability to generate split DWARF directly: 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.