Supporting > 2GiB text sections in SFrame/EH_Frame

[Indu Bhagat]

On 9/4/25 8:37 AM, Sterling Augustine wrote:
> On Wed, Sep 3, 2025 at 10:13 PM Indu Bhagat <indu.bhagat@oracle.com 
> <mailto: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.
> 

I do like the idea of keeping just start_addr and size together for 
binary search, and moving rest to the FRE sub-section.

This gives better cache locality to the binary search of SFrame FDEs.

> 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.
> 

Reducing num_fres from uint32_t to uint16_t should bring us half of the 
percentage gain seen when measuring the SFrame size increase from 
uint32_t sfde_func_start_address --> uint64_t sfde_func_start_address 
(which was 6-7%).  So this means ~3% size decrease, with possibly some 
padding.

While not negligible, it not going to be a big win either.

>     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.
> 

Are the current sizes in acceptable category ?

It will be good to know so we can prioritize this for SFrame V3 (I 
intend to target SFrame V3 for 2.46 release).

Thanks