Re: [PATCH v13 00/18] unwind_deferred: Implement sframe handling

[Jens Remus]

On 2/11/2026 2:47 AM, Dylan Hatch wrote:
> On Tue, Jan 27, 2026 at 7:06 AM Jens Remus <jremus@xxxxxxxxxxxxx> wrote:
>>
>> This is the implementation of parsing the SFrame V3 stack trace information
>> from an .sframe section in an ELF file.  It's a continuation of Josh's and
>> Steve's work that can be found here:
>>
>>    https://lore.kernel.org/all/cover.1737511963.git.jpoimboe@xxxxxxxxxx/
>>    https://lore.kernel.org/all/20250827201548.448472904@xxxxxxxxxx/
>>
>> Currently the only way to get a user space stack trace from a stack
>> walk (and not just copying large amount of user stack into the kernel
>> ring buffer) is to use frame pointers. This has a few issues. The biggest
>> one is that compiling frame pointers into every application and library
>> has been shown to cause performance overhead.
>>
>> Another issue is that the format of the frames may not always be consistent
>> between different compilers and some architectures (s390) has no defined
>> format to do a reliable stack walk. The only way to perform user space
>> profiling on these architectures is to copy the user stack into the kernel
>> buffer.
>>
>> SFrame [1] is now supported in binutils (x86-64, ARM64, and s390). There is
>> discussions going on about supporting SFrame in LLVM. SFrame acts more like
>> ORC, and lives in the ELF executable file as its own section. Like ORC it
>> has two tables where the first table is sorted by instruction pointers (IP)
>> and using the current IP and finding it's entry in the first table, it will
>> take you to the second table which will tell you where the return address
>> of the current function is located and then you can use that address to
>> look it up in the first table to find the return address of that function,
>> and so on. This performs a user space stack walk.
>>
>> Now because the .sframe section lives in the ELF file it needs to be faulted
>> into memory when it is used. This means that walking the user space stack
>> requires being in a faultable context. As profilers like perf request a stack
>> trace in interrupt or NMI context, it cannot do the walking when it is
>> requested. Instead it must be deferred until it is safe to fault in user
>> space. One place this is known to be safe is when the task is about to return
>> back to user space.
>>
>> This series makes the deferred unwind user code implement SFrame format V3
>> and enables it on x86-64.
>>
>> [1]: https://sourceware.org/binutils/wiki/sframe
>>
>>
>> This series applies on top of the tip perf/core branch:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  perf/core
>>
>> The to be stack-traced user space programs (and libraries) need to be
>> built with the recent SFrame stack trace information format V3, as
>> generated by the upcoming binutils 2.46 with assembler option --gsframe.
>> It can be built from source from the binutils-2_46-branch branch:
>>
>>   git://sourceware.org/git/binutils-gdb.git  binutils-2_46-branch

> Do you by chance have this work uploaded in a public branch somewhere?
> I'd like to get a new version of the SFrame for reliable stacktrace on
> arm64 patch series [1] working for SFrame V3, ideally with the SFrame
> library in your patch series here.
> 
> https://lore.kernel.org/lkml/20250904223850.884188-1-dylanbhatch@xxxxxxxxxx/
No, I don't.  Following is how you can easily get to tip:perf/core with
this work applied using b4:

$ git checkout -b sframe v6.18
$ git pull --no-rebase git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core # pre-req for [PATCH v13 00/18] unwind_deferred: Implement sframe handling
$ b4 shazam -T 20260127150554.2760964-1-jremus@xxxxxxxxxxxxx # [PATCH v13 00/18] unwind_deferred: Implement sframe handling

Following is how you can get to a tervolds:master with all of the latest
sframe related series on top using b4:

$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master:sframe
$ git checkout sframe
$ b4 shazam -T 20260127150554.2760964-1-jremus@xxxxxxxxxxxxx # [PATCH v13 00/18] unwind_deferred: Implement sframe handling
$ git am -3 # resolve "unwind_user/sframe: Store .sframe section data in per-mm maple tree"
$ git am -3 # partially resolve "unwind_user/sframe: Add prctl() interface for registering .sframe sections"
$ git mergetool # manually resolve prctl.h and kernel/sys.c conflicts; bump PR_ADD_SFRAME and PR_REMOVE_SFRAME; each case must end with break;
$ git am --continue
$ b4 shazam -T 20260211141357.271402-1-jremus@xxxxxxxxxxxxx # optional [PATCH v9 0/6] x86/vdso: VDSO updates and fixes for sframes
$ b4 shazam -T 20260127151926.2805123-1-jremus@xxxxxxxxxxxxx # optional [PATCH v4 00/12] s390: SFrame user space unwinding
$ git am -3 # partially resolve "s390/vdso: Enable SFrame V3 generation in vDSO"
$ git mergetool # manually resolve arch/s390/kernel/vdso/Makefile conflict
$ git am --continue
$ git am -3 # resolve "s390/ptrace: Convert function macros to inline functions"

Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
jremus@xxxxxxxxxx / jremus@xxxxxxxxxxxxx

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/