On Thu, 11 Jun 2026 00:00:25 -0700 Fangrui Song <[email protected]> wrote:
> Hi Steven, > > This is not an objection to deferred userspace unwinding itself -- my > concern is narrower: these syscalls permanently encode the kernel's > commitment to the SFrame format family at exactly the moment the > format's size trajectory is heading the wrong way, and while arguably > superior formats exist. > > I raised related size concerns about SFrame's viability for userspace > stack walking earlier: > https://lore.kernel.org/all/3xd4fqvwflefvsjjoagytoi3y3sf7lxqjremhe2zo5tounihe4@3ftafgryadsr/ > ("Concerns about SFrame viability for userspace stack walking") > > SFrame v3 is even larger than v2. > > For comparison: Microsoft is currently upstreaming its Windows x64 > Unwind V3 implementation to LLVM, which will make a side-by-side reading > of the two formats straightforward. Unwind V3 provides correct > exception-handling unwind -- full prologue replay, SEH handlers, > funclets -- and supports Intel APX. SFrame v3 provides stack tracing > only, no EH, yet comes out larger than .eh_frame. A format revision that > adds capability without adding bulk is demonstrably achievable; SFrame > v3 went the other way. My main concern is simplicity in implementation on the kernel side. One thing we would like to avoid is any interpreter that becomes basically executing user space code to perform the stack tracing (i.e. DWARF). I haven't looked at the Windows x64 but will do so. > > I understand IBM is doubling down on SFrame for their s390x and ppc64, That's because this is currently the only way s390 can perform stack walking in user space. > but I'm not convinced the size overhead of v3 will make it appealing on > x86-64. I have learned that the person driving their SFrame work at > Google had left and the SFrame at data center effort was being > reevaluated per a toolchain manager. I believe the person who left Google that was driving the SFrame work was me ;-) Thanks, -- Steve
