# Re: \[PATCH v10 00/14\] unwind\_user: x86: Deferred unwinding infrastructure

- From: Andrii Nakryiko \<hidden\>
- Date: 2025-06-12 23:30:14 
- List: linux-trace-kernel
- Page: https://ratatoskr.run/linux-trace-kernel/2025/06/3090155
- Thread: https://ratatoskr.run/linux-trace-kernel/2025/06/3086227/t.md

```text
On Thu, Jun 12, 2025 at 3:02 PM Josh Poimboeuf [ref] wrote:
>
> On Thu, Jun 12, 2025 at 02:44:18PM -0700, Andrii Nakryiko wrote:
> > On Tue, Jun 10, 2025 at 6:03 PM Steven Rostedt [ref] 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?
>
> https://github.com/llvm/llvm-project/issues/64449

Great, thank you!

>
> --
> Josh
```