GNU Tools Cauldron SFrame talk notes

[Indu Bhagat]

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.

[1] SFrame wiki:https://sourceware.org/binutils/wiki/sframe