GNU Tools Cauldron SFrame talk notes

[Steven Rostedt]

On Fri, 10 Oct 2025 01:09:00 -0700
Indu Bhagat <indu.bhagat@oracle.com> wrote:

> 
> Hi Fangrui,
> 
> Kernel relocatable files is not the sole reason of the design choice of 
> having an index.  Without an index, stacktracers will have a run-time 
> hit of parsing the section to create an index or resorting to linear 
> scan; neither of these is acceptable for performance reasons.
> 
> > The fundamental design issue lies in making linker merging mandatory.
> > For optimal portability, unwinders should support multiple-element
> > structures within a .sframe section. When a linker builds an index for
> > .sframe, it should be viewed as an optimization that relieves the
> > unwinder from constructing its own index at runtime. This index
> > construction should remain optional rather than required. While the
> > SFRAME_F_FDE_SORTED flag can be cleared to permit unsorted FDEs,
> > current unwinder implementations do not seem to support multiple
> > elements in a single section.
> >   
> 
> Constructing index at runtime will hurt.  Kernel's stacktracing of 
> userspace stacks will be done on the return to user path, and cannot 
> take that sort of performance hit.

Question:

Each object being linked would have a sorted sframe table, correct?

It's just that if the linker doesn't know what an sframe is, it would just
concatenate all the sections placing several sorted sections together but
the whole is not sorted?

> 
> Its not just the kernel, building the index at run-time will hurt _all_ 
> other profiling and debugging use-cases where fast stack traces are 
> desirable.
> 

Is it possible to have the sframe header denote this? That is, if the
linker knows about sframes, it would sort the entire section and set a flag
in the sframe header that it is sorted. If not, then the kernel and other
profilers could implement a slow path. Where at first read, it would create
a secondary table of each sorted section, and sort that. This table would
likely need to be allocated per task. We could possibly attach it to the
inode of the executable so that if there's more than one instance of it
running, they would all use the same table.

Then for searching the FDE via the instruction pointer, it would first look
at the created outer table (which would be in sorted format such that it
still can do a binary search) and then do a binary search of the inner table.

Yes, this may be more work on the reader of the sframe sections, but if
this will simplify the linker side, it could be worth it.

-- Steve