On Thu, Jun 11, 2026 at 4:23 AM Steven Rostedt [off-list ref] wrote:

On Thu, 11 Jun 2026 00:00:25 -0700
Fangrui Song [off-list ref] wrote:

quoted

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/ (local)
("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%

quoted

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.

quoted

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.