Debug Information Is Huge and What to Do About It
documentation.backtrace.io
Debug Information Is Huge and What to Do About It
1–10 of 21 posts
Re: Debug Information Is Huge and What to Do About It
#2Please Arch Linux developers: stop stripping all packages of debug symbols
Re: Debug Information Is Huge and What to Do About It
#3Please Arch Linux developers: stop stripping all packages of debug symbols
Isn't it a common practice to strip, but keep them in separately published files that only contain symbols?
Re: Debug Information Is Huge and What to Do About It
#4Re: Debug Information Is Huge and What to Do About It
#5Use build-id (https://fedoraproject.org/wiki/Releases/FeatureBuildId), strip the debug info into its own object file, and point gdb at your debug objects when it comes time to debug.
Lean distributable binaries, yet still debugable. Win-win.
Re: Debug Information Is Huge and What to Do About It
#6Minor typo:
> 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!
Re: Debug Information Is Huge and What to Do About It
#7Minor typo: > 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!
Whoops, good catch! I will fix, thanks.
Re: Debug Information Is Huge and What to Do About It
#8Solaris developed another solution, specifically CTF (Compressed Type Format). CTF stores data types and function signatures rather than full debug info, and is therefore much smaller than the DWARF information it is derived from.
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.
Re: Debug Information Is Huge and What to Do About It
#9Please Arch Linux developers: stop stripping all packages of debug symbols
Sigh.
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
Re: Debug Information Is Huge and What to Do About It
#10Please Arch Linux developers: stop stripping all packages of debug symbols
Sigh. 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
If you build packages yourself, one can either include debug info, or generate a split package that includes debug info.
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.