Re: Concerns about SFrame viability for userspace stack walking

On Thu, Oct 30, 2025 at 09:48:50AM -0700, Fangrui Song wrote:

> Thanks for this perspective???the unwinder complexity concern is
> absolutely valid and critical for kernel use.
> To clarify my motivation: I've seen attempts to use SFrame for
> userspace adoption
> (https://fedoraproject.org/wiki/Changes/SFrameInBinaries ), and I
> believe it's not viable for that purpose given the size overhead I
> documented. My concerns are primarily about userspace adoption, not
> the kernel's internal unwinding.
> 
> If SFrame is exclusively a kernel-space feature, it could be
> implemented entirely within objtool ??? similar to how objtool --link
> --orc generates ORC info for vmlinux.o. This approach would eliminate
> the need for any modifications to assemblers and linkers, while
> allowing SFrame to evolve in any incompatible way.
> 
> For userspace, we could instead modify assemblers and linkers to
> support a more compact format or an extension to .eh_frame , but it
> won't be SFrame (all of Apple???s compact unwind, ARM EHABI???s
> exidx/extab, and Microsoft???s pdata/xdata can implement C++ exception
> handling , while SFrame can't, leading to a huge missed opportunity.)

No, you misunderstand. The x86_64 Linux kernel is using ORC internally
and we're happy with that. However, the kernel also needs to be able to
unwind/walk user stack frames.

We need simple robust means of walking user space stacks from the kernel.

It is here that SFrame is proposed on x86_64. The kernel consumes user
space SFrame data to unwind user space stacks. This is also why the
SFrame sections are SHF_ALLOC, such that the kernel can simply fault
them in on-demand without having to otherwise initiate IO.