[PATCH,V1 00/14] Definition and support for SFrame unwind format

[Indu Bhagat]

On 9/30/22 01:24, Fangrui Song wrote:
> On 2022-09-29, Indu Bhagat via Binutils wrote:
>> What is SFrame format and why do we need it
>> -------------------------------------------
>> SFrame format is the Simple Frame format.  It can be used to represent 
>> the
>> minimal necessary information for backtracing.  As such, it only 
>> encodes how to
>> recover the CFA (based on SP/FP) and the return address (RA) for all
>> instructions of a program.
>>
>> The format is supported on AMD64 and AARCH64 ABIs only.  The 
>> information stored
>> in the .sframe section is a subset of what .eh_frame can convey: 
>> .eh_frame can
>> convey how to resurrect all callee-saved registers, if need be; but 
>> .sframe
>> does not.
>>
>> SFrame format is intended for usecases where fast virtual stack unwind is
>> needed, along with a need for a small simple unwinder. So, those 
>> applications
>> which struggle with the following two complaints will want to consider 
>> SFrame
>> format:
>>  - EH Frame based unwinders are complex and slow to manage with
>>  - EH Frame based unwinders are large as they need to deal with DWARF
>>  opcodes via a stack machine implementation
>>
>> More details about the format are available in include/sframe.h, 
>> please see
>> commit "sframe.h: Add SFrame format definition".
>>
>> Our not-so-exhaustive experiments (basically binutils programs built with
>> -Wa,--gsframe) show that SFrame/EH Frame section ratio to be an 
>> average of 0.8x
>> for x86_64 and 0.7x for aarch64.
> 
> For an executable with 1000KiB .eh_frame, .sframe takes 800KiB?
> Does SFrame has something similar to .eh_frame_hdr and what is the size
> comparison? The saving isn't apealing in my view.
> 

Small correction - For an executable with 1000KiB of 
.eh_frame+.eh_frame_hdr sections, .sframe takes 800KiB.

Yes, SFrame has something similar to .eh_frame_hdr.  The SFrame FDE 
(Function Descriptor Entries) are sorted on start PC by the linker 
before writing out the .sframe section.

Re: size comparison of the index in SFrame vs .eh_frame_hdr - The size 
numbers I quote is the ratio of .sframe/(.eh_frame + .eh_frame_hdr) size 
for binutils programs. As SFrame FDEs contain more information than the 
individual entry in the .eh_frame_hdr, I don't know if this comparison 
will fetch us much insight.

Re : space saving appeal - SFrame's "reason for existence" is to allow 
fast unwinding while using a simple unwinder. The stack offsets, for 
example, are encoded directly rather than being calculated at the time 
of backtracing.  Such a representation will need more space when 
compared to the opcode-based encoding in EH Frame format in isolation. 
That said, there might be some more optimization opportunities to 
explore for reducing the size of SFrame further.

> Have you tried removing callee-saved register information from
> .eh_frame?
> 

I haven't tried this yet. BTW, other folks also were curious about this 
at Cauldron.

This keeps getting pushed lower on my task list, however, because the 
outcome of the experiment does not change the fact that there are 
applications where fast, plain vanilla backtracing is needed using a 
simple backtracer. Such a comparison can be informative though, I see that.

> Has SFrame be compared with macOS compact unwind descriptors, Windows
> ARM64 exception handling, MIPS compact exception tables (their .eh_frame
> counterpart, not the .gcc_except_table counterpart)?

I havent looked at them closely enough to offer a meaningful comparison 
at this time. I will take a second look.

Thanks