All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miguel Ojeda <ojeda@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alex Gaynor <alex.gaynor@gmail.com>,
	Wedson Almeida Filho <wedsonaf@google.com>
Subject: [PATCH v6 17/23] scripts: decode_stacktrace: demangle Rust symbols
Date: Sat,  7 May 2022 07:24:15 +0200	[thread overview]
Message-ID: <20220507052451.12890-18-ojeda@kernel.org> (raw)
In-Reply-To: <20220507052451.12890-1-ojeda@kernel.org>

Recent versions of both Binutils (`c++filt`) and LLVM (`llvm-cxxfilt`)
provide Rust v0 mangling support.

Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com>
Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com>
Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com>
Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
I would like to use this patch for discussing the demangling topic.

The following discusses the different approaches we could take.


# Leave demangling to userspace

This is the easiest and less invasive approach, the one implemented
by this patch.

The `decode_stacktrace.sh` script is already needed to map
the offsets to the source code. Therefore, we could also take
the chance to demangle the symbols here.

With this approach, we do not need to introduce any change in the
`vsprintf` machinery and we minimize the risk of breaking user tools.

Note that, if we take this approach, it is likely we want to ask
for a minimum version of either of the tools (since there may be
users of the script that do not have recent enough toolchains).


# Demangling in kernelspace on-the-fly

That is, at backtrace print time, we demangle the Rust symbols.

The size of the code that would be needed is fairly small; around
5 KiB using the "official" library (written in Rust), e.g.:

    text    data    bss     dec      hex    filename
    7799976 1689820 2129920 11619716 b14d84 vmlinux
    7801111 1693916 2129920 11624947 b161f3 vmlinux + demangling

We can remove a few bits from the official library, e.g. punycode
support that we do not need (all our identifiers will be ASCII),
but it does not make a substantial difference.

The official library performs the demangling without requiring
allocations. However, of course, it will increased our stack usage
and complexity, specially considering a stack dump may be requested
in not ideal conditions.

Furthermore, this approach (and the ones below) likely require adding
a new `%p` specifier (or a new modifier to existing ones) if we do
not want to affect non-backtrace uses of the `B`/`S` ones. Also,
it is unclear whether we should write the demangled versions in an
extra, different line or replace the real symbol -- we could be
breaking user tools relying on parsing backtraces (e.g. our own
`decode_stacktrace.sh`). For instance, they could be relying on
having real symbols there, or may break due to e.g. spaces.


# Demangling at compile-time

This implies having kallsyms demangle all the Rust symbols.

The size of this data is around the same order of magnitude of the
non-demangled ones. However, this is notably more than the demangling
code (see previous point), e.g. 120 KiB (uncompressed) in a
small kernel.

This approach also brings the same concerns regarding modifying
the backtrace printing (see previous point).


# Demangling at compile-time and substituting symbols by hashes

One variation of the previous alternative is avoiding the mangled
names inside the kernel, by hashing them. This would avoid having
to support "big symbols" and would also reduce the size of the
kallsyms tables, while still allowing to link modules.

However, if we do not have the real symbols around, then we do not
have the possibility of providing both the mangled and demangled
versions in the backtrace, which brings us back to the issues
related to breaking userspace tools. There are also other places
other than backtraces using "real" symbols that users may be
relying on, such as `/proc/*/stack`.


 scripts/decode_stacktrace.sh | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/scripts/decode_stacktrace.sh b/scripts/decode_stacktrace.sh
index 5fbad61fe490..f3c7b506d440 100755
--- a/scripts/decode_stacktrace.sh
+++ b/scripts/decode_stacktrace.sh
@@ -8,6 +8,14 @@ usage() {
 	echo "	$0 -r <release> | <vmlinux> [<base path>|auto] [<modules path>]"
 }
 
+# Try to find a Rust demangler
+if type llvm-cxxfilt >/dev/null 2>&1 ; then
+	cppfilt=llvm-cxxfilt
+elif type c++filt >/dev/null 2>&1 ; then
+	cppfilt=c++filt
+	cppfilt_opts=-i
+fi
+
 if [[ $1 == "-r" ]] ; then
 	vmlinux=""
 	basepath="auto"
@@ -169,6 +177,12 @@ parse_symbol() {
 	# In the case of inlines, move everything to same line
 	code=${code//$'\n'/' '}
 
+	# Demangle if the name looks like a Rust symbol and if
+	# we got a Rust demangler
+	if [[ $name =~ ^_R && $cppfilt != "" ]] ; then
+		name=$("$cppfilt" "$cppfilt_opts" "$name")
+	fi
+
 	# Replace old address with pretty line numbers
 	symbol="$segment$name ($code)"
 }
-- 
2.35.3


  parent reply	other threads:[~2022-05-07  5:29 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-07  5:23 [PATCH v6 00/23] Rust support Miguel Ojeda
2022-05-07  5:23 ` Miguel Ojeda
2022-05-07  5:23 ` Miguel Ojeda
2022-05-07  5:23 ` Miguel Ojeda
2022-05-07  5:23 ` [PATCH v6 01/23] kallsyms: avoid hardcoding the buffer size Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 02/23] kallsyms: support "big" kernel symbols Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 03/23] kallsyms: increase maximum kernel symbol length to 512 Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 04/23] kunit: take `kunit_assert` as `const` Miguel Ojeda
2022-05-12 19:01   ` Brendan Higgins
2022-05-07  5:24 ` [PATCH v6 05/23] rust: add C helpers Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 06/23] rust: add `compiler_builtins` crate Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 07/23] rust: import upstream `alloc` crate Miguel Ojeda
2022-05-07  9:23   ` Kees Cook
2022-05-07  9:33     ` Miguel Ojeda
2022-05-07 17:06       ` Kees Cook
2022-05-07 17:30   ` Linus Torvalds
2022-05-07 19:34     ` Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 08/23] rust: adapt `alloc` crate to the kernel Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 09/23] rust: add `build_error` crate Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 10/23] rust: add `macros` crate Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 11/23] rust: add `kernel` crate's `sync` module Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 12/23] rust: add `kernel` crate Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 13/23] rust: export generated symbols Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 14/23] vsprintf: add new `%pA` format specifier Miguel Ojeda
2022-05-07  8:19   ` Kees Cook
2022-05-07  9:35     ` Miguel Ojeda
2022-05-10  8:38   ` Petr Mladek
2022-05-10 10:45     ` Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 15/23] scripts: add `rustdoc_test_{builder,gen}.py` scripts Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 16/23] scripts: add `generate_rust_analyzer.py` scripts Miguel Ojeda
2022-05-07  5:24 ` Miguel Ojeda [this message]
2022-05-07  8:32   ` [PATCH v6 17/23] scripts: decode_stacktrace: demangle Rust symbols Kees Cook
2022-05-07 10:21     ` Miguel Ojeda
2022-05-07 17:09       ` Kees Cook
2022-05-07  5:24 ` [PATCH v6 18/23] docs: add Rust documentation Miguel Ojeda
2022-05-07  8:15   ` Kees Cook
2022-05-07  8:45     ` Miguel Ojeda
2022-05-09  4:02   ` Akira Yokosawa
2022-05-09 10:41     ` Miguel Ojeda
2022-05-09 14:56       ` Akira Yokosawa
2022-05-09 22:37         ` Jonathan Corbet
2022-05-10 11:57           ` Miguel Ojeda
2022-05-09 22:32   ` Jonathan Corbet
2022-05-10  3:14     ` Gaelan Steele
2022-05-10  5:53       ` Josh Triplett
2022-05-11 13:49     ` Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 19/23] Kbuild: add Rust support Miguel Ojeda
2022-05-07  5:24   ` Miguel Ojeda
2022-05-07  5:24   ` Miguel Ojeda
2022-05-07  5:24   ` Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 20/23] samples: add Rust examples Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 21/23] MAINTAINERS: Rust Miguel Ojeda
2022-05-07  8:06   ` Kees Cook
2022-05-07  5:24 ` [PATCH v6 22/23] [RFC] drivers: gpio: PrimeCell PL061 in Rust Miguel Ojeda
2022-05-07  5:24 ` [PATCH v6 23/23] [RFC] drivers: android: Binder IPC " Miguel Ojeda
2022-05-07  7:55   ` Kees Cook
2022-05-07  8:13     ` Greg Kroah-Hartman
2022-05-09 17:52       ` Todd Kjos
2022-05-07  8:06 ` [PATCH v6 00/23] Rust support Kees Cook
2022-05-07  8:06   ` Kees Cook
2022-05-07  8:06   ` Kees Cook
2022-05-07  8:06   ` Kees Cook
2022-05-08 18:06   ` Matthew Wilcox
2022-05-08 18:06     ` Matthew Wilcox
2022-05-08 18:06     ` Matthew Wilcox
2022-05-08 18:06     ` Matthew Wilcox
2022-05-09  9:39   ` Wei Liu
2022-05-09  9:39     ` Wei Liu
2022-05-09  9:39     ` Wei Liu
2022-05-09  9:39     ` Wei Liu
2022-05-07  9:29 ` David Gow
2022-05-07  9:29   ` David Gow
2022-05-07  9:29   ` David Gow
2022-05-07  9:29   ` David Gow
2022-05-07 15:03   ` Miguel Ojeda
2022-05-07 15:03     ` Miguel Ojeda
2022-05-07 15:03     ` Miguel Ojeda
2022-05-07 15:03     ` Miguel Ojeda
2022-05-10  4:44     ` David Gow
2022-05-10  4:44       ` David Gow
2022-05-10  4:44       ` David Gow
2022-05-10  4:44       ` David Gow
2022-05-10 11:36       ` Miguel Ojeda
2022-05-10 11:36         ` Miguel Ojeda
2022-05-10 11:36         ` Miguel Ojeda
2022-05-10 11:36         ` Miguel Ojeda

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=20220507052451.12890-18-ojeda@kernel.org \
    --to=ojeda@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jarkko@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=wedsonaf@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.