On 2/11/2026 2:47 AM, Dylan Hatch wrote: > On Tue, Jan 27, 2026 at 7:06 AM Jens Remus <[email protected]> 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/[email protected]/ >> https://lore.kernel.org/all/[email protected]/ >> >> 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/[email protected]/ 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 [email protected] # [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 [email protected] # [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 [email protected] # optional [PATCH v9 0/6] x86/vdso: VDSO updates and fixes for sframes $ b4 shazam -T [email protected] # 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) [email protected] / [email protected] 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/
