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-kbuild@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>, Alex Gaynor <alex.gaynor@gmail.com>, Wedson Almeida Filho <wedsonaf@google.com> Subject: [PATCH 13/19] scripts: decode_stacktrace: demangle Rust symbols Date: Mon, 6 Dec 2021 15:03:07 +0100 [thread overview] Message-ID: <20211206140313.5653-14-ojeda@kernel.org> (raw) In-Reply-To: <20211206140313.5653-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.34.0
next prev parent reply other threads:[~2021-12-06 14:06 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-06 14:02 [PATCH 00/19] Rust support Miguel Ojeda 2021-12-06 14:02 ` [PATCH 01/19] kallsyms: support "big" kernel symbols Miguel Ojeda 2021-12-06 14:18 ` Matthew Wilcox 2021-12-06 17:00 ` Miguel Ojeda 2021-12-06 14:02 ` [PATCH 02/19] kallsyms: increase maximum kernel symbol length to 512 Miguel Ojeda 2021-12-06 14:02 ` [PATCH 03/19] kallsyms: use the correct buffer size for symbols Miguel Ojeda 2021-12-06 14:02 ` [PATCH 04/19] rust: add C helpers Miguel Ojeda 2021-12-06 14:02 ` [PATCH 05/19] rust: add `compiler_builtins` crate Miguel Ojeda 2021-12-07 23:01 ` Nick Desaulniers 2021-12-09 19:34 ` Miguel Ojeda 2021-12-06 14:03 ` [PATCH 07/19] rust: add `build_error` crate Miguel Ojeda 2021-12-06 14:03 ` [PATCH 08/19] rust: add `macros` crate Miguel Ojeda 2021-12-06 14:03 ` [PATCH 10/19] rust: export generated symbols Miguel Ojeda 2021-12-06 14:03 ` [PATCH 11/19] vsprintf: add new `%pA` format specifier Miguel Ojeda 2021-12-06 15:02 ` Greg Kroah-Hartman 2021-12-06 15:56 ` Miguel Ojeda 2021-12-06 16:02 ` Greg Kroah-Hartman 2021-12-06 19:52 ` Nick Desaulniers 2021-12-06 19:55 ` Matthew Wilcox 2021-12-06 20:02 ` Nick Desaulniers 2021-12-06 14:03 ` [PATCH 12/19] scripts: add `generate_rust_analyzer.py` Miguel Ojeda 2021-12-06 14:03 ` Miguel Ojeda [this message] 2021-12-06 14:03 ` [PATCH 14/19] docs: add Rust documentation Miguel Ojeda 2021-12-08 1:29 ` Nick Desaulniers 2021-12-08 23:07 ` Miguel Ojeda 2021-12-06 14:03 ` [PATCH 15/19] Kbuild: add Rust support Miguel Ojeda 2021-12-07 22:45 ` Nick Desaulniers 2021-12-07 23:21 ` Nick Desaulniers 2021-12-07 23:25 ` Wedson Almeida Filho 2021-12-08 0:05 ` Nick Desaulniers 2021-12-08 22:52 ` Miguel Ojeda 2021-12-11 15:53 ` Masahiro Yamada 2022-01-17 4:45 ` Miguel Ojeda 2021-12-06 14:03 ` [PATCH 16/19] samples: add Rust examples Miguel Ojeda 2021-12-06 14:03 ` [PATCH 17/19] MAINTAINERS: Rust Miguel Ojeda 2021-12-06 14:03 ` [RFC PATCH 18/19] drivers: gpio: PrimeCell PL061 in Rust Miguel Ojeda [not found] ` <20211206140313.5653-20-ojeda@kernel.org> 2021-12-06 15:01 ` [RFC PATCH 19/19] drivers: android: Binder IPC " Greg Kroah-Hartman 2021-12-06 15:59 ` Wedson Almeida Filho 2021-12-06 16:02 ` Greg Kroah-Hartman
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=20211206140313.5653-14-ojeda@kernel.org \ --to=ojeda@kernel.org \ --cc=alex.gaynor@gmail.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=rust-for-linux@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=wedsonaf@google.com \ --subject='Re: [PATCH 13/19] scripts: decode_stacktrace: demangle Rust symbols' \ /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
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).