Ubuntu 24.04 LTS will enable frame pointers by default

Original Article ↗ Hacker News Discussion ↗

Ubuntu 24.04 LTS will compile binaries with frame pointers enabled by default, reversing an older optimization that omitted them to gain an extra register on 32‑bit x86. Commenters argue that on modern 64‑bit CPUs the performance hit is typically well under 1–2%, while the gains in observability are substantial: far more reliable stack traces, easier use of tools like perf, eBPF/bpftrace, and continuous profilers, plus better post-mortem debugging even without full debug symbols. Some worry about regressions in highly sensitive workloads such as Python’s interpreter, but the emerging consensus is that distributions should favor debuggability by default and selectively opt out only for workloads where a clear, measurable slowdown appears.

Background and rationale

  • Many commenters see omitting frame pointers as a legacy micro‑optimization from 32‑bit x86, where reclaiming the frame pointer gave a crucial extra register and large speedups.
  • On x86‑64 there are many more and wider registers, so the benefit of omitting the frame pointer is viewed as much smaller.
  • Several note other distros (e.g., Fedora) already enable frame pointers and view Ubuntu’s move as part of a broader trend.

Performance impact debate

  • Reported overhead on 64‑bit architectures is usually “hard to measure,” often below 1%, with some claims of 1–2% in specific workloads.
  • Critics argue even 0.1–1% global regressions are wasteful at scale and that tools should just be fixed to profile without frame pointers.
  • Supporters counter that easy access to profiles often yields 30–3000% optimizations, making the tradeoff strongly favorable.
  • Some mention micro‑cases where the extra register is still important (bytecode interpreters like Python, tight hot loops), and expect or endorse per‑package opt‑outs.

Debugging and profiling benefits

  • Strong consensus that frame pointers make stack unwinding trivial, cheap, and more reliable, especially for:
    • Perf, eBPF/bpftrace/bcc tools, continuous profiling, and flame graphs.
    • Post‑mortem debugging, core dumps, and production incident analysis on LTS systems.
  • Without frame pointers, tools must use DWARF/.eh_frame unwind programs, which are slower, more complex, and fragile when stacks are corrupted.

Tooling, formats, and kernel support

  • Several describe existing solutions to unwind without frame pointers using DWARF+eBPF, but note they are complex and not widely available or suitable for all tools.
  • Discussion of kernel ORC unwinder for the kernel itself and emerging SFrame format for future user‑space stack unwinding with lower overhead.
  • Some argue relying on advanced unwind formats is unrealistic today; frame pointers work immediately with existing tooling.

Special cases, security, and ecosystem impact

  • Python is cited as having seen ~10% regressions with frame pointers; Ubuntu plans to exclude such cases if confirmed.
  • Embedded systems often strip debug/unwind info, making frame pointers particularly valuable there.
  • One comment notes omitting frame pointers slightly reduces certain stack‑overflow exploit surfaces, but this line of reasoning is not developed.
  • There is debate over whether such defaults should be set by distros or left to upstreams; others respond that operators and users also need system‑wide observability.