Re: [PATCH v4 17/39] unwind_user/sframe: Add support for reading .sframe headers

[Josh Poimboeuf]

On Wed, Feb 05, 2025 at 02:56:36PM +0100, Jens Remus wrote:
> On 29.01.2025 03:02, Josh Poimboeuf wrote:
> 
> > Note FDEs aren't even needed here as the unwinder doesn't need to know
> > when a function begins/ends.  The only info needed by the unwinder is
> > just the fre_data struct.  So a simple binary search of fres[] is all
> > that's really needed.
> 
> In SFrame V2 FDEs specify ranges bound by function start address and
> length.  FREs in contrast specify open ranges bounded by start address.
> Their effect ends either with the next FRE becoming into effect or when
> their FDE range ends.
> This concept enables holes in the .text section which do not have any
> valid FDE/FRE information associated.
> 
> Your proposal lacks some sort of mechanism to replicate those holes.
> It could be FDEs with a flag (or no offsets?) that specifies their
> range has no valid information.

In ORC, a hole is simply specified by an ORC entry (aka "FRE") of type
UNDEFINED.

That could be done here as well: the linker would replace a gap with an
"undefined" FRE which could be identified either by setting a bit in the
FRE header, or by using a special fre_data[] entry.  For example,
fre_data index 0 could just be a placeholder for the undefined FRE type.

-- 
Josh