From: Jakub Jelinek <jakub@redhat.com>
To: Fangrui Song <maskray@sourceware.org>
Cc: linux-toolchains@vger.kernel.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Concerns about SFrame viability for userspace stack walking
Date: Thu, 30 Oct 2025 09:05:53 +0100 [thread overview]
Message-ID: <aQMcYe5BK+Rsu3xF@tucnak> (raw)
In-Reply-To: <CAN30aBHOw16Tzdn_Z0TZKie7Fyi39bmB2PQK4LB-rjU1vn3zQQ@mail.gmail.com>
On Thu, Oct 30, 2025 at 12:50:42AM -0700, Fangrui Song wrote:
> An effective compact unwinding scheme needs to leverage ISA-specific properties.
Having 40-50 completely different unwinding schemes, one for each
architecture or even ISA subset, would be a complete nightmare. Plus the
important property of DWARF is that it is easily extensible. So, I think it
would be better to invent new DWARF DW_CFA_* arch specific opcodes which
would be a shorthand for the most common sequences of unwind info, or allow
the CIEs to define a library of DW_CFA_* sets perhaps with parameters which
would then be usable in the FDEs. There are already some arch specific
opcodes, DW_CFA_GNU_window_save for SPARC and
DW_CFA_AARCH64_negate_ra_state_with_pc/DW_CFA_AARCH64_negate_ra_state for
AArch64, but if somebody took time to look through .eh_frame of many
binaries/libraries on several different distributions for particular arch
(so that there is no bias in what exact options those distros use etc.) and
found something that keeps repeating there commonly that could be shortened,
perhaps the assembler or linker could rewrite sequences of specific .cfi_*
directives into something equivalent but shorter once the extension opcodes
are added. Though, there are only very few opcodes left, so taking them
should be done with great care and at least one should be left as a
multiplexer (single byte opcode followed by uleb128 code for further
operation + arguments).
Jakub
next prev parent reply other threads:[~2025-10-30 8:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-30 6:53 Concerns about SFrame viability for userspace stack walking Fangrui Song
2025-10-30 7:30 ` Jakub Jelinek
2025-10-30 7:50 ` Fangrui Song
2025-10-30 8:05 ` Jakub Jelinek [this message]
2025-10-31 2:51 ` Fangrui Song
2025-10-30 10:26 ` Peter Zijlstra
2025-10-30 16:48 ` Fangrui Song
2025-10-30 17:03 ` Jose E. Marchesi
2025-10-31 4:22 ` Fangrui Song
2025-10-31 14:37 ` Jose E. Marchesi
2025-10-30 17:33 ` Steven Rostedt
2025-10-31 5:28 ` Fangrui Song
2025-10-30 18:22 ` Peter Zijlstra
2025-10-30 17:53 ` Andi Kleen
2025-10-30 18:07 ` Mark Brown
2025-10-30 18:31 ` Andi Kleen
2025-10-30 18:45 ` Mark Brown
2025-10-31 8:24 ` Fangrui Song
2025-10-30 18:57 ` Peter Zijlstra
2025-10-31 11:46 ` Mark Brown
2025-10-30 14:47 ` Jose E. Marchesi
2025-11-04 9:21 ` Indu
2025-11-05 8:21 ` Fangrui Song
2025-11-06 0:44 ` Indu Bhagat
2025-11-06 7:51 ` Florian Weimer
2025-11-06 21:02 ` Indu Bhagat
2025-11-06 9:20 ` Fangrui Song
2025-11-06 20:42 ` Indu Bhagat
2025-11-09 0:23 ` Fangrui Song
2025-12-01 9:04 ` Fangrui Song
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=aQMcYe5BK+Rsu3xF@tucnak \
--to=jakub@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=maskray@sourceware.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