GNU Tools Cauldron SFrame talk notes

[Fangrui Song]

On Thu, Oct 23, 2025 at 2:42 PM Indu Bhagat <indu.bhagat@oracle.com> wrote:
> On 10/18/25 10:34 AM, Fangrui Song wrote:
> > This alternative design makes the assembler's .sframe section
> > unnecessary and is worth exploring.
> > This design allows the linker to merge and optimize the .eh_frame
> > section as usual (which requires CIE and FDE boundary information).
> > The linker then analyzes the CFI instructions (a step previously
> > unneeded) and generates the .sframe section.
> > Since the linker only reads the stable .eh_frame and produces .sframe,
> > there's no mix-and-match concern.
> >
> > CFI instruction decoding introduces additional complexity. However,
> > this is balanced by the architectural advantage of centralizing the
> > logic;
> > it avoids scattering processing code (similar to SHF_MERGE and
> > .eh_frame) across the linker code.
> > However, this fine-grained knowledge of the format may expose the
> > linker to more frequent updates—a serious risk, given that the
> > linker's foundational role in the build process demands exceptional
> > stability and robustness.
> >
>
> I agree with the observation of this route introduces additional
> complexity.  I'd expect the overhead of parsing DWARF CFI and processing
> CFI to generate SFrame data at link time to be more than what we have
> today (merging input SFrame data at link-time).

Thank you for the response.

> I am also not sure ATM about how will this fit in the linker workflow
> (and if managing this itself brings additional section specific handling
> in the generic linker parts): There are linker generated .eh_frame
> sections (for .plt* sections), which are merged to create the final
> .eh_frame output.  The suggested process of SFrame data creation will
> need to be deferred until such merging of EH Frame data is complete...

I think --ld-generated-unwind-info is a legacy feature
https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#no-ld-generated-unwind-info

    However, I think this feature is obsolete and no longer relevant.
To recognize the PLT name, a profiler needs to:

    Parse the .plt section to identify the region of PLT entries
    Parse .rel[a].plt to get R_*_JUMP_SLOT dynamic relocations and
their referenced symbol names
    If the current PC is within the PLT region, parse nearby
instructions and find the GOT load. The associated R_*_JUMP_SLOT
identifies the symbol name
    Concatenate the symbol name and @plt to form foo@plt
    Note: foo@plt is a convention used by some tools, but it is not a
name in the symbol table.

    gdb has heuristics to identify this situation.

For AArch32, AArch64, and Power, there will be range extension thunks (veneer).
Similarly, I don't think linkers should synthesize unwind information
for those areas.

> > A key related technical point concerns the section flags: we must
> > confirm if .sframe truly requires the SHF_ALLOC flag.
> > perf supports .debug_frame (tools/perf/util/unwind-libunwind-local.c),
> > which does not have the SHF_ALLOC flag. Removing SHF_ALLOC from
> > .sframe would significantly simplify the process for any post-link
> > tool seeking to append or modify the unwind information, allowing them
> > to add new sections with greater ease.
> >
>
> SFrame requires SHF_ALLOC.
>
> This ensures that SFrame is available in the program memory.
> Non-SHF_ALLOC SFrame will hurt tracers, and in-process stack tracing
> usecases, because the cost of mmap is not amortized over the runtime of
> the application. Cost is one only aspect; in some critical scenarios at
> the time when backtrace is needed, bringing in a section is not viable.
>
> RE: perf supports .debug_frame which is SHF_ALLOC.
> There is a difference between status quo and whether the status quo is
> the best we can do.

Can you elaborate on the runtime tracing use case?

With SHF_ALLOC, .sframe contributes to initial read-only data segment
consumption but can be accessed directly as part of the memory-mapped area.
With non-SHF_ALLOC, while there's no upfront cost, the tracer must open the
file and mmap the section on demand. You raise a valid concern that this
runtime cost may not be amortized well.

However, as I mentioned in my other reply, I believe most users will
not need stack trace features. This raises the question: is having
.sframe loaded as part of the read-only data segment (.eh_frame,
.rodata) an acceptable overhead for distributions?

To quantify this, I've analyzed 337 files in /usr/bin and
/usr/lib/x86_64-linux-gnu/ on my system:

EH_Frame ratio statistics:
  Min: 0.3024%
  Max: 11.5175%
  Mean: 5.2481%
  Median: 5.1202%

Distribution:
  0%-1%: 7 files
  1%-2%: 17 files
  2%-3%: 37 files
  3%-4%: 49 files
  4%-5%: 50 files
  5%-6%: 62 files
  6%-7%: 33 files
  7%-8%: 36 files
  8%-9%: 20 files
  9%-10%: 20 files
  10%-12%: 6 files

If .sframe size is comparable to .eh_frame size, this would represent
quite significant overhead for applications that never use stack
tracing.

> > A more cautious and immediate strategy is available: existing Linux
> > distribution post-processing tools can be modified to append the
> > .sframe section to executable and shared object files.
>
> @Fangrui,
> Do you think this intermediate solution is usable to build the huge
> fleet of a variety of userspace packages for a distro ?  How can one
> then test the fleet with SFrame data ?

Fair question. Post-processing tools would require integration into
package build systems, which admittedly introduces more friction than
native linker support.

> > Full .sframe merge into linkers should only be considered after this
> > section has conclusively proved its value and stability over
> > established unwind mechanisms.
> Integrating support for SFrame in GNU ld has undeniably helped with
> adoption and maturation of the format, with close attention to feature
> set and implementation fixes from the wider GNU/Linux community.  The
> feature set of V3 is a curated list of developers' inputs and feature
> requests possible only because of complete support available in the
> assembler/linker.
>
> We are going in circles here again on this one, so I will say no more.
>
> Thanks
> Indu

My primary concern stems from observing the binutils mailing list—I see
a significant volume of SFrame commits, though I'm uncertain how many
are linker-related. Most linker features stabilize quickly after their
initial implementation. Given the linker's foundational role, which
demands exceptional stability and robustness, I'm concerned about the
ongoing maintenance implications.

That said, I do acknowledge the value of having this support in the
toolchain for iterating on the format. The early integration has
clearly provided valuable feedback for the format's evolution, even if
my concerns about long-term maintenance burden remain.

Thanks for the thoughtful discussion.