https://bbs.archlinux.org/viewtopic.php?id=174250
https://bugs.archlinux.org/task/10975
https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces
still not clear if it was ever implemented
The piece that may still be missing is the inclusion of source code in debug packages, which is necessary to get any context for a debug session (it is not sufficient to seek out and clone random git repos because of versioning & patching differences).
But ideally, there would be a `-debug` package for every package in arch's repos, and one would not need to build them manually when debug symbols are needed. Arch does not have this.
The entire Solaris system is built with CTF enabled, which is used to support their debuggers and dtrace. Other systems have adopted it too. OpenBSD is moving to use CTF, and has enabled it's use in the kernels and debuggers on some architecture.
To get a sense of the size difference, DWARF information for a sparc64 kernel is about 27 megabytes. The CTF information derived from it is 473 kilobytes.
So you'll still end up disassembling the thing to figure out which register to look at. And you might as well do that on the unstripped binary on your development box. For embedded targets at least, that's a small price to pay for a size reduction of that magnitude.
CTF is obviously less capable than DWARF, but it is small enough to ship by default and in my experience it is Good Enough(tm) for most debugging needs.
I noticed that clang seems to be better at generating correct infos in such modes.
Otherwise I use GDB in "batch mode" to get a callstack triggered by raise(SIGTRAP):
> gdb -quiet --batch -ex run -ex backtrace --args $binary $@
It's better than nothing, but consider using something like libunwind instead.
The ultimate goal is to get a backtrace without debug symbol (in release) but I don't know any method to achieve that without instrumentation.
Lean distributable binaries, yet still debugable. Win-win.
The next step up in convenience is having the source-level debugger understand how to fetch the corresponding source files from a server based on revision IDs or content hashes.
Between those two features, you can open a core dump on any machine, and immediately have access to both debug info and source without manually mucking around with anything. If you spend a lot of time looking at core dumps from a myriad of different programs and versions of those programs, this is a lifesaver.
> A more efficient representation of .debug_rnglists introduced in DWARF 5.
Should probably read:
> A more efficient representation of .debug_ranges introduced in DWARF 5.
Edit: Tangentially, I loved https://backtrace.io/blog/compile-once-debug-twice-picking-a... and am still looking forward to parts 2 and 3. Thanks!
