Task #5279
closedReduce amount of debugging information in compiled binaries
100%
Description
I'd like to propose changing our default CXXFLAGS to reduce the amount of debug info that ends up in the compiled object files and eventually in the final binaries.
Motivation¶
The goal is to have smaller binaries and (in some cases) shorter build times without affecting the debugging experience too much (including symbolization of stack traces). Yes, it's already possible for users to manually strip the final binaries, but unless we integrate stripping in ./waf install
somehow, I think it's fair to assume that no one is doing it in practice when building from source (the PPA packages are a different story). Moreover, stripping destroys any chances of debugging or obtaining human-readable stack traces, while still paying the increased time and memory cost during compilation, so it's arguably worse than keeping a minimal/reduced amount of debug info in the binary.
Status quo¶
The current default CXXFLAGS contain -g
(equivalent to -g2
) in release builds and -g3
in debug builds. See GCC documentation on debugging options. The corresponding clang options have very similar, if not identical, semantics.
Reduced debug info¶
My suggestion is to switch release builds to -g1
and debug builds to -g2
.
I have verified that, at least on Linux/GCC, -g1
is sufficient to produce human-readable function names in stack traces. This is also stated in the GCC documentation.
By downgrading from -g3
to -g2
we lose information on the macro definitions present in the program, but I've personally never had to use this functionality in a debugger. And if there is a (very rare) case where this is needed, it's easy enough to change the flag to -g3
and recompile.
Most Linux distros use "split" debug info, which is typically handled automatically as part of the package build process, so it probably makes sense to override the (release) flags to restore -g
/-g2
for our PPA packages.
Compressed debug sections¶
Another flag we could consider in the future, either in addition or in alternative to this proposal, is -gz
which uses zlib to produce compressed debug sections.
Updated by Davide Pesavento over 1 year ago
- Subject changed from Reduce amount of debug info produced by default to Reduce amount of debugging information in compiled binaries
- Status changed from New to In Progress
- % Done changed from 0 to 20
g1 |
g1 +gz |
g2 |
g2 +gz |
g3 |
g3 +gz |
|
---|---|---|---|---|---|---|
Release (size) | 819M | 737M | 1.4G | 1.1G | ||
Release (time) | 4m38s | 4m36s | 6m3s | 6m5s | ||
Debug (size) | 1.2G | 953M | 1.6G | 1.2G | ||
Debug (time) | 3m25s | 3m28s | 3m48s | 3m42s |
Note: don't pay too much attention to the columns with gz
. I included them just to give a rough idea of the tradeoffs of using compressed debug sections. And there are different ways to enable compression (e.g., final link only vs. all intermediate object files) which will give different results. Also, these numbers were obtained with LLD. The BFD linker is a bit slower when compression is enabled.
Updated by Davide Pesavento over 1 year ago
ndn-tools, gcc 12.3.0, lld 15.0.7
- release, no tests
- size: 154M → 38M
- time (-j2): 1m33s → 1m16s
- release, with tests
- size: 264M → 65M
- time (-j2): 2m38s → 2m1s
- debug, with tests
- size: 276M → 198M
- time (-j2): 1m48s → 1m46s
Updated by Davide Pesavento over 1 year ago
- Status changed from In Progress to Code review
- % Done changed from 20 to 100
Updated by Davide Pesavento over 1 year ago
- Status changed from Code review to Closed