On most Linux platforms (except AArch32, which uses .ARM.exidx ), DWARF .eh_frame is required for C++ exception handling and stack unwinding to restore callee-saved registers. While .eh_frame can be used for call trace recording, it is often criticized for its runtime overhead. As an alternative, developers can enable frame pointers, or adopt SFrame, a newer format designed specifically for profiling. This article examines the size overhead of enabling non-DWARF stack walking mechanisms when building several LLVM executables.
Runtime performance analysis will be added in a future update.
Stack walking mechanisms
Here is a survey of mechanisms available for x86-64:
Frame pointers: fast but costs a register
DWARF .eh_frame : comprehensive but slower, supports additional features like C++ exception handling
: comprehensive but slower, supports additional features like C++ exception handling SFrame: a new format being developed, profiling only. .eh_frame is still needed for debugging and C++ exception handling. Check out Remarks on SFrame for details.
is still needed for debugging and C++ exception handling. Check out Remarks on SFrame for details. x86 Last Branch Record (LBR): Skylake increased the LBR stack size to 32. Supported by AMD Zen 4 as Last Branch Record Extension Version 2 (LbrExtV2)
Apple's Compact Unwinding Format: This has llvm, lld/MachO, and libunwind implementation. Supports x86-64 and AArch64. This can mostly replace DWARF CFI, but some entries need DWARF escape.
OpenVMS's Compact Unwinding Format: This modifies Apple's Compact Unwinding Format.
... continue reading