[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250630133016.0d2ee00d@batman.local.home>
Date: Mon, 30 Jun 2025 13:30:16 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
bpf@...r.kernel.org, x86@...nel.org, Masami Hiramatsu
<mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra
<peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, Jiri Olsa
<jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Thomas Gleixner
<tglx@...utronix.de>, Andrii Nakryiko <andrii@...nel.org>, Indu Bhagat
<indu.bhagat@...cle.com>, "Jose E. Marchesi" <jemarch@....org>, Beau
Belgrave <beaub@...ux.microsoft.com>, Jens Remus <jremus@...ux.ibm.com>,
Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton
<akpm@...ux-foundation.org>, Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH v11 00/14] unwind_user: x86: Deferred unwinding
infrastructure
On Mon, 30 Jun 2025 14:50:52 +0200
Florian Weimer <fweimer@...hat.com> wrote:
> * Steven Rostedt:
>
> > SFrames is now supported in gcc binutils and soon will also be supported
> > by LLVM.
>
> Is the LLVM support discussed here?
>
> [RFC] Adding SFrame support to llvm
> <https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900>
>
> Or is there a secone effort?
Not a second effort, but also discussed here:
https://github.com/llvm/llvm-project/issues/64449
I know internally at Google, it's being worked on. One of the
motivations for getting LLVM to support sframes is to allow live kernel
patching on arm64. Live kernel patching is currently only supported on
x86 because it requires the ORC unwinder. Which is Josh's creation (and
works basically the same way as sframes do) to have reliable stack
traces in the kernel at run time. It's been stated that porting ORC to
other archs would be too much, but since sframes do basically the same
thing, and would support multiple architectures, then it makes sense to
use sframes instead of ORC.
>
> > I have more patches on top of this series that add perf support, ftrace
> > support, sframe support and the x86 fix ups (for VDSO). But each of those
> > patch series can be worked on independently, but they all depend on this
> > series (although the x86 specific patches at the end isn't necessarily
> > needed, at least for other architectures).
>
> Related to perf support: I'm writing up the SFrame change proposal for
> Fedora, and I want to include testing instructions. Any idea yet what a
> typical “perf top” or “perf report” command line would look like?
I'll be posting updated patches soon and will Cc you. I'll also include
git branches that contain the patches. You'll need the core patches
(what this patch set is), the perf updates and the sframe patches.
The perf patches contain both the kernel side and user space side to
update perf.
Note, to make sure sframes are working properly, I also add
"trace_printk()" into the code and make sure that the sframes code is
being executed and used (it falls back to frame pointers if they fail).
I'll post a patch that includes the trace_printk() that I use as well.
But obviously that wouldn't be something you would add to your
documentation. It's mostly FYI for you.
Hopefully I'll have them done either tonight or tomorrow.
-- Steve
Powered by blists - more mailing lists