GNU Tools Cauldron SFrame talk notes

[Fangrui Song]

On 10/20/25 11:31 PM, Indu Bhagat wrote:
> (V2 should not be present out in the wild.  Since this thread is the
> focus of multiple communities ATM, I want to ensure less misinformation
> builds up.)
>
>  V3 is the version we are targeting to converge to and start from (in
> userspace). This is important to keep in mind.  There is a reason the
> interested parties here (Linux distros, toolchain developers, kernel
> developers) have agreed to do so: lesser code base and maintenance
> burden, lesser bugs/issues for everyone involved.
>
> V3's original feature list was an exhaustive collection of all review
> comments, shortcomings seen so far with V2 (collected over a span of
> about a yr).  Will the next version bump need a similar varied feature
> set ?  I dont think so.

I appreciate the clarification about V3 being the non-experimental starting
point.

> As I mentioned earlier, #3 is a burden for stack tracers.  This is not
> doable for usecases like tracing, profiling and in-process stack tracing.
>
> Previous reply to this (See "I am not convinced that --sframe-index as
> opt-in is the right choice."
> https://sourceware.org/pipermail/binutils/2025-October/144898.html)
>
> As it stands, having stack tracers create the index *cannot* be a part
> of the solution, because we are trying to solve the problem of "fast
> stacktracing".
>
> Let me restate:
> If there is a solution to merge SFrame sections, to create stack trace
> information along with an index, using existing/new ELF provisions, I
> would like to hear about it.  The index creation overhead cannot be
> borne by stack tracers, and the solution must keep the Linux distros in
> mind for testing and deployment.

I understand your performance requirements, but you're conflating two separate
issues: whether linkers should *support* SFrame indexing (which I agree with if
there is substantial demand) versus whether it should be *default* behavior
(which I oppose).

The core problem: user programs may receive .sframe sections from system
libraries even when users don't need stack tracing functionality. These
users must still deal with:

- Mix-and-match version problems when linking against prebuilt libraries
- Linkers that have dropped support for legacy SFrame versions
- Linkers that don't support SFrame at all

As I mentioned in
https://sourceware.org/pipermail/binutils/2025-October/144974.html:

    Having SFrame in prebuilt libraries doesn't mean users need it, yet they
    must handle any issues arising from merging different versions.

Distribution shipping a feature does not make it ubiquitous. Most users will
not need stack tracing features—this may change eventually, but that will take
many years. In the meantime, they must accept unneeded information while
handling the resulting compatibility issues.

>> 4. Distros enable via compiler drivers once the format stabilizes
>>
>> This *is* toolchain-proper support. The distinction is opt-in vs. default.
>>
>> Your approach:
>>
>> - Violates ELF conventions
>> - Forces all linkers to implement version-specific merging
>>
>> In lld/ELF, linker-created sections are called synthetic sections.
>> No synthetic section requires version-specific merging.
>> Even the quite complex .gdb_index section doesn't require this, proving its
>> stability after years. Why not let .sframe follow a similar maturation path
>> through opt-in support first?
>
> Because the path of "opt-in support" leads to stack tracers needing to
> create the index at run time.

Runtime merging support is necessary for optimal portability (e.g. old linker).
A library can be provided to share code between GNU ld and the kernel.

Making .sframe's design fundamentally incompatible with the concatenation
convention would not be a good idea. If you still want to bring up
SHF_OS_NONCONFORMING_DISCARD,
you can create a topic on https://groups.google.com/g/generic-abi .
I think there is nearly zero chance this will get adopted, though.

While stack unwinding performance is critical for your use cases, you cannot
assume universal adoption. Requiring linkers to build indices by default is
a significant departure from how all other metadata sections work, imposing
costs on users who don't need the feature.

>> ---
>>
>> To move forward constructively, please address the problems I raised in:
>> https://sourceware.org/pipermail/binutils/2025-October/144904.html
>
> I already did reply
> https://sourceware.org/pipermail/binutils/2025-October/144967.html
>
> If there is a specific concern unanswered, please let me know.

Your response essentially argues that "SFrame-aware linkers can handle older
SFrame versions without much difficulty" while opposing opt-in --sframe-index.
I disagree with both positions.

The opt-in approach I've proposed provides a clear path forward:

    If .sframe ever becomes ubiquitous like RELRO, you could make an argument
    for making indexing the default—but even then, you could achieve this
    through compiler drivers rather than changing linker defaults.

This allows the format to mature and prove its value before imposing
mandatory support on all linkers.