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

[Fangrui Song]

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.

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

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)?