More compact SFrames through deduplication

[Steven Rostedt]

On Tue, 27 Jan 2026 01:06:16 +0900
Tatsuyuki Ishi <ishitatsuyuki@gmail.com> wrote:

> I took the time to turn this into a full proposal:
> https://github.com/ishitatsuyuki/binutils/blob/sframe2cframe/libsframe/packed-table.md
> 
> This is a PoC written with lots of assist from AI, but there is also a ./binutils/sframe2cframe tool

Hmm, I'd be interested in what AI prompts you used ;-)

> in the tree, that takes a binary with SFrame and outputs a CFrame formatted file.  When
> --chunk-dwarf is specified it also does the heuristics chunking described in the proposal. The
> heuristics requires parsing .eh_frame.
> 
> Using some locally created eh_frame to SFrame converter, I gathered the size numbers on
> libvulkan_radeon.so (~7MB .text) for Clang and GCC generated binaries:
> 
> - Clang fp: SFrame 394702 bytes, CFrame 146670 bytes
> - Clang no-fp: SFrame 601900 bytes, CFrame 153561 bytes
> - GCC fp: SFrame 511711 bytes, CFrame 174045 bytes
> - GCC no-fp: SFrame 824558 bytes, CFrame 398175 bytes

These are great results!

> 
> Deduplication performs worse on GCC, which is because it schedules prologs/epilogs into regular
> instructions. That said, the packed scheme yields a net benefit.
> 
> The proposed design also puts the burden on the linker to pack up the table. As long as chunking is
> done beforehand by the compiler, the linker does not need to parse the FRE. It only needs to
> parse the FDE table to do the bit packing. Deduplication can be done on FRE strings blindly.
> 
> Let me know about your thoughts on the trade-offs.

I'll let the compiler experts comment on it.

Thanks Tatsuyuki!

-- Steve