Project

General

Profile

Actions

Task #5279

closed

Reduce amount of debugging information in compiled binaries

Added by Davide Pesavento 9 months ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Category:
Build
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

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.

Actions #1

Updated by Davide Pesavento 9 months ago

  • Description updated (diff)
Actions #2

Updated by Davide Pesavento 9 months 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.

Actions #3

Updated by Davide Pesavento 9 months 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
Actions #4

Updated by Davide Pesavento 9 months ago

  • Status changed from In Progress to Code review
  • % Done changed from 20 to 100
Actions #5

Updated by Davide Pesavento 9 months ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF