Re: [PATCH v10 00/14] unwind_user: x86: Deferred unwinding infrastructure

[Andrii Nakryiko]

On Tue, Jun 10, 2025 at 6:03 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
>
> Hi Peter and Ingo,
>
> This is the first patch series of a set that will make it possible to be able
> to use SFrames[1] in the Linux kernel. A quick recap of the motivation for
> doing this.
>
> 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.
>
> SFrames is now supported in gcc binutils and soon will also be supported
> by LLVM. SFrames acts more like ORC, and lives in the ELF executable

Is there any upstream PR or discussion for SFrames support in LLVM to
keep track of?

> 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.
>

[...]