Supporting > 2GiB text sections in SFrame/EH_Frame

[Sterling Augustine]

On Wed, Sep 3, 2025 at 10:13 PM Indu Bhagat <indu.bhagat@oracle.com> wrote:

> > A. A simple one would be to have the first X bytes at
> > sfde_func_start_fre_off be the total size of the function, instead of
> > an FRE.  If the fretype is ADDRX, then the first X bytes are the total
> size.
> > This makes it easy to find the total size, at the expense of the FREs
> being
> > slightly-non-uniform.
> >
>
> To me, this is simpler than B. But the catch here is that FRE
> sub-section, by design, favors compaction.  This means that the FRE data
> may be unaligned (this includes sfre_start_address and the stack
> offsets).  With the function size now going to the FRE sub-section, this
> may be now an additional unaligned access...
>

Another possibility, and probably a better one, would be to keep the size
in the
fde subsection, and move num_fres, func_info, and rep_sizeto in the fre
subsection.
Thus, the FDE subsection has everything needed to find the unwind info and
the fre
subsection has everything needed to unwind once you have the location. This
is
quite a bit closer to your desire to keep the roles separate.

If num_fres is a uint16_t, then it can be aligned in the fre subsection at
an average
cost of a half-byte per function. (and func_start_fre_off points directly
to it so there
the alignment padding won't confuse the readers.) Given that this makes an
FDE
only 16 bytes (in the 64-bit format), its still a pretty big size win, and
there are no
additional unaligned accesses.


> Function size needs to be easily accessible for stack tracers to do
> binary search effectively.  Because there can be holes between PC ranges
> per function, it (function size) is a vital piece of info needed to do
> the work of "find the FDE for a given PC".  So I would say, if we go
> this route, this should be the first FRE.
>

The above idea obviates this, but once you have the nearest
not-greater-than
fde--easily findable by binary search without size checks--it only takes a
single
size probe to see if the pc is inside the found FDE. This optimization
avoids a
size check at every step of the search until the last, and probably ought
to be
done even if size is immediately available.


> Overall though, I would attempt to keep the separation between what FDEs
> are meant for (function level metadata) vs what FREs are meant for (Per
> PC range stack trace metadata).
>

This newer idea is hopefully more acceptable as it keeps "finding the
unwind info"
in the fde section, and "what to do once you have it" in the fre section,
and it saves
a lot of space. But it's up to you of course.

BTW, for a subset of binaries generated for GNU Binutils package, my
> back-of-the-envelope calculations suggest a 6-7% increase in SFrame
> section size if using 64-bit FDEs over 32-bit FDEs.
>

Very large binaries are already quite unwieldy, so the smaller the better,
from our
side. Size will be a significant part of the criteria for adoption inside
Google. If it
ends up not meeting our needs, we will figure something else out. But  we
are
hoping that it does.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20250904/b52dba51/attachment.htm>