From: Steven Rostedt <rostedt@goodmis.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
bpf@vger.kernel.org, x86@kernel.org,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andrii Nakryiko <andrii@kernel.org>,
Indu Bhagat <indu.bhagat@oracle.com>,
"Jose E. Marchesi" <jemarch@gnu.org>,
Beau Belgrave <beaub@linux.microsoft.com>,
Jens Remus <jremus@linux.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH v11 00/14] unwind_user: x86: Deferred unwinding infrastructure
Date: Mon, 30 Jun 2025 13:30:16 -0400 [thread overview]
Message-ID: <20250630133016.0d2ee00d@batman.local.home> (raw)
In-Reply-To: <878ql9mlzn.fsf@oldenburg.str.redhat.com>
On Mon, 30 Jun 2025 14:50:52 +0200
Florian Weimer <fweimer@redhat.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
next prev parent reply other threads:[~2025-06-30 17:30 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-25 22:56 [PATCH v11 00/14] unwind_user: x86: Deferred unwinding infrastructure Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 01/14] unwind_user: Add user space unwinding API Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 02/14] unwind_user: Add frame pointer support Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 03/14] unwind_user: Add compat mode " Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 04/14] unwind_user/deferred: Add unwind_user_faultable() Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 05/14] unwind_user/deferred: Add unwind cache Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 06/14] unwind_user/deferred: Add deferred unwinding interface Steven Rostedt
2025-06-26 16:48 ` Steven Rostedt
2025-06-26 20:34 ` Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 07/14] unwind_user/deferred: Make unwind deferral requests NMI-safe Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 08/14] unwind deferred: Use bitmask to determine which callbacks to call Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 09/14] unwind deferred: Use SRCU unwind_deferred_task_work() Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 10/14] unwind: Clear unwind_mask on exit back to user space Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 11/14] unwind: Finish up unwind when a task exits Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 12/14] unwind_user/x86: Enable frame pointer unwinding on x86 Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 13/14] perf/x86: Rename and move get_segment_base() and make it global Steven Rostedt
2025-06-26 8:44 ` Ingo Molnar
2025-06-26 12:13 ` Steven Rostedt
2025-06-26 13:07 ` Peter Zijlstra
2025-06-26 15:13 ` Steven Rostedt
2025-06-25 22:56 ` [PATCH v11 14/14] unwind_user/x86: Enable compat mode frame pointer unwinding on x86 Steven Rostedt
2025-06-26 8:33 ` Ingo Molnar
2025-06-26 12:12 ` Steven Rostedt
2025-06-27 14:01 ` Steven Rostedt
2025-06-27 16:23 ` Linus Torvalds
2025-06-30 12:50 ` [PATCH v11 00/14] unwind_user: x86: Deferred unwinding infrastructure Florian Weimer
2025-06-30 16:35 ` Namhyung Kim
2025-06-30 17:30 ` Steven Rostedt [this message]
2025-07-02 11:44 ` Sam James
2025-07-02 16:15 ` Steven Rostedt
2025-07-02 17:14 ` Namhyung Kim
2025-07-03 4:01 ` Sam James
2025-07-02 17:10 ` Namhyung Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250630133016.0d2ee00d@batman.local.home \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=axboe@kernel.dk \
--cc=beaub@linux.microsoft.com \
--cc=bpf@vger.kernel.org \
--cc=fweimer@redhat.com \
--cc=indu.bhagat@oracle.com \
--cc=jemarch@gnu.org \
--cc=jolsa@kernel.org \
--cc=jpoimboe@kernel.org \
--cc=jremus@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).