On Thu, Jun 11, 2026 at 4:23 AM Steven Rostedt <[email protected]> wrote:
>
> 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 recognize interpreter complexity as a real and valid concern (though
I believe the concern can be alleviated with a good use of LLM
auditing).
But the SFrame family's size problem is more pressing than it's being
given credit for, because of a point that applies specifically to
x86-64: SFrame cannot *replace* .eh_frame there, only add to it (to
keep debugging and C++ exception handling working).
.eh_frame+.eh_frame_hdr almost takes 9%; adding .sframe adds another 9% on top.
I don't think the perceived benefit on x86-64 justifies near-doubling
the unwind metadata footprint.
x86-64 experiments with x64 Unwind V3 for ELF:
unwind B VM B % of VM
sqlite3 -O0
.eh_frame(+hdr) 42,120 446,735 9.43%
Win64 v1 24,536 438,609 5.59%
Win64 v3 33,296 450,889 7.38%
SFrame v3 39,105 440,727 8.87%
sqlite3 -O1
.eh_frame(+hdr) 44,424 479,348 9.27%
Win64 v1 15,496 450,724 3.44%
Win64 v3 21,816 458,916 4.75%
SFrame v3 44,756 477,776 9.37%
CGExpr.cpp -O3
.eh_frame(+hdr) 27,040 372,416 7.26%
Win64 v1 10,720 356,080 3.01%
Win64 v3 15,320 360,185 4.25%
SFrame v3 27,628 370,912 7.45%
> >
> > 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.
Hmm, I think that DWARF .eh_frame already works on s390x, but I take
your word that .sframe might be appealing for some use cases.
Perhaps s390x and x86-64 shouldn't be decided by the same vote.
> > 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
Ha, I wasn't referring to you. I had a different toolchain engineer in mind.
But that was a secondhand aside and not the point I want to rest
anything on, so I'll set it aside and stick to the bytes.
-----
Separately, on maturity and sequencing:
On timing: the SFrame v3 binutils set was first posted 2025-12-09; the
2.46 branch was cut 2026-01-17 and released 2026-02-08 with v3
generation. That's a ~5-week window, and I'm not convinced there's
been time for rigorous review of the v3 design; if flaws surface we're
at a v4, and kernel adoption still wouldn't be a given.
