GNU Tools Cauldron SFrame talk notes

[Indu Bhagat]

On 10/24/25 8:10 AM, Tatsuyuki Ishi wrote:
>> On Oct 9, 2025, at 8:14, Indu Bhagat <indu.bhagat@oracle.com> wrote:
>>
>> Hi,
>>
>> A brief summary of two SFrame-related items discussed at GNU Tools Cauldron
>> 2025 (talk on "SFrame for effective userspace stack tracing"
>> https://conf.gnu-tools-cauldron.org/opo25/talk/ADVMH7/). More details on SFrame
>> stack trace format can be found on the wiki [1].  Thanks for your inputs during
>> the session and all the hallway chats.
>>
>> * Handling in SFrame unaware linkers
>>
>>   For the case of distro-wide enablement where the assembler generates an
>>   SFrame section, but the used linker does not support merging of SFrame
>>   sections, following link-time failures will be seen:
>>
>>     error: relocation refers to a discarded section: XYZ
>>
>>   The error is in accordance with the ELF specification (handling of unknown
>>   section type), and the eventual resolution is to support merging of SFrame
>>   sections.
>>
>>   As per the ELF specification
>> (https://gabi.xinuos.com/elf/03-sheader.html#rules-for-linking-unrecognized-sections):
>>    - "Unrecognized sections that do not have the SHF_OS_NONCONFORMING attribute,
>>      are combined in a two-phase process."
>>    - "In the first phase, input sections that match in name, type and attribute
>>      flags should be concatenated into single sections."
>>
>>   We discussed how this default behaviour proves to be a limitation to allow
>>   new section types (SFrame being one example), where
>>    - the new section type's layout is such that concatenated output is not
>>      meaningful/useful.
>>    - not all link-editors may want to deal with the new section type.
>>
>>   It may be worthwhile to explore the possibility of adjusting the ELF
>>   specification to have SFrame sections be marked with a new flag, such that
>>   the default linker behavior of concatenating the sections can be skipped.
>>
>>   The above issue is a blocker for SFrame enablement on some distros. Further,
>>   some distros reportedly have as many as 8 linkers.  If ELF can be adjusted, the
>>   currently SFrame-unaware linkers can discard the SFrame section.
>>
>>   After the discussion at Cauldron, I think the following addition to ELF may
>>   work:
>>
>>   SHF_OS_NONCONFORMING_DISCARD (new flag)
>>   This section requires special OS-specific processing (beyond the standard
>>   linking rules) to avoid incorrect behavior. If this section has either an
>>   sh_type value or contains sh_flags bits in the OS-specific ranges for those
>>   fields, and a link editor processing this section does not recognize those
>>   values, then the link editor should discard the section without an error.
>>
>>   WRT relocations, I think the following may work (does this need to be
>>   specified?):
>>   Any section linked via sh_link must also be discarded.  Sections with flag
>>   SHF_OS_NONCONFORMING_DISCARD cannot have any relocations referring to these
>>   sections from outside of the section.
>>
>>   WDYT ?
>>
>> * Linker-friendly SFrame section layout
>>
>>   We also discussed the question of whether it is possible to make SFrame
>>   handling linker-friendly.
>>
>>   One of the possible options was to split SFrame section so that link-editors
>>   can assemble final section without needing to understand the contents of the
>>   section.
>>
>>   Separate SFrame data into three sections
>>   - SFrame header (.sframe_header)
>>     flags = SHF_ALLOC
>>   - SFrame function index (FDEs sorted on start PC) (say, .sframe_idx),
>>     flags = SHF_LINK_ORDER | SHF_ALLOC
>>   - SFrame FRE data (concatenable, say .sframe_info)
>>     flags = SHF_ALLOC
>>
>>   Use linker script to place the header first, followed by .sframe_idx, and
>>   finally .sframe_info.  For linkers which work without linker script, they
>>   usually assume sections are placed in alphabetical order.  But since we need
>>   the linker script to emit some vital section (header) data like number of FDEs,
>>   using linker scripts has a major drawback that SFrame will simply be
>>   unsupported on some linkers.  Its also not clear how/where to emit one header
>>   with all the necessary bits like number of FDEs and other offsets. Getting rid
>>   of the header or duplicating the header SFrame FRE data is a no-go:
>>    - SFrame header holds vital information like version, flags and other
>>      provisions necessary for format evolution
>>    - It is wasteful to duplicate it for each set of function FREs (in
>>      .sframe_info).  It will bloat up the format considerably.
>>
>>   So, it seems the general advise was to not rely on linker script mechanism.
>>   Above all, making the layout linker-friendly with this approach adversely
>>   affects the efficacy of the format.
> 
> In light of recent discussions, I was re-reading the thread and thought this
> might be worth revisiting.
> 
> The advantage of using existing linker constructs is that you have a clear
> contract between SFrame and the linker. The linker is not in charge of
> providing compat; if compat works through that linker construct, then you have
> forward and backward compat.
> 
> Merging the header is indeed harder. I imagine that one would take the maximum
> version across all object files and union of the flags, but AFAIK there are no
> ELF constructs for that (closest is IMAGE_COMDAT_SELECT_LARGEST in PE). So it
> seems reasonable to have custom merging for the header only. I strongly suggest
> specifying the linker contract (i.e. merging rules) in the spec, e.g. how each
> field should be merged, to avoid the slippery slope of “linkers DTRT” (which is
> not possible if you don’t specify DTRT before upgrading the spec).
> 

Yes, that is a good idea. We could add a section around "linker 
considerations" in the specification outlining the expectations.