11:06 p.m.
Currently, the kernel has supported Rust, and it has been
enabled in some distributions by default. So the crash tool
can not resolve the mangled Rust symbols on such vmcores.
For example:
crash> bt
PID: 3520 TASK: ffff8f240f670000 CPU: 1 COMMAND: "insmod"
#0 [ffffd08c4f063a20] machine_kexec at ffffffff9575e60e
#1 [ffffd08c4f063a40] __crash_kexec at ffffffff958db711
#2 [ffffd08c4f063b00] panic at ffffffff9560cede
#3 [ffffd08c4f063b80] _RNvCscb18lrEyTSA_10rust_panic10area_in_hp at ffffffffc07fe107
[rust_panic]
#4 [ffffd08c4f063c20] _RNvMCscb18lrEyTSA_10rust_panicNtB2_10HelloPanic8step_two at
ffffffffc07fe160 [rust_panic]
#5 [ffffd08c4f063cf0] do_one_initcall at ffffffff956c7aaa
...
The patchset will solve the current issues, the crash tool
reuses the rust demangle lib in gdb to demangle the mangled
Rust symbol into human-readable symbol.
With the patchset:
crash> bt
PID: 3520 TASK: ffff8f240f670000 CPU: 1 COMMAND: "insmod"
#0 [ffffd08c4f063a20] machine_kexec at ffffffff9575e60e
#1 [ffffd08c4f063a40] __crash_kexec at ffffffff958db711
#2 [ffffd08c4f063b00] panic at ffffffff9560cede
#3 [ffffd08c4f063b80] rust_panic::area_in_hp at ffffffffc07fe107 [rust_panic]
#4 [ffffd08c4f063c20] <rust_panic::HelloPanic>::step_two at ffffffffc07fe160
[rust_panic]
#5 [ffffd08c4f063cf0] do_one_initcall at ffffffff956c7aaa
...
crash> sym "rust_panic::area_in_hp"
ffffffffc07fe010 (t) rust_panic::area_in_hp [rust_panic]
/root/linux-6.16.3/samples/rust/rust_panic.rs: 22
crash> dis "rust_panic::area_in_hp"
0xffffffffc07fe010 <rust_panic::area_in_hp>::area_in_hp>: push %rbx
0xffffffffc07fe011 <rust_panic::area_in_hp+1>::area_in_hp+1>: sub
$0x90,%rsp
0xffffffffc07fe018 <rust_panic::area_in_hp+8>::area_in_hp+8>: mov
%rdi,%rbx
0xffffffffc07fe01b <rust_panic::area_in_hp+11>::area_in_hp+11>: movq
$0xffffffffc0bd5020,(%rsp)
0xffffffffc07fe023 <rust_panic::area_in_hp+19>::area_in_hp+19>: movq
$0x1,0x8(%rsp)
0xffffffffc07fe02c <rust_panic::area_in_hp+28>::area_in_hp+28>: movq
$0x0,0x20(%rsp)
0xffffffffc07fe035 <rust_panic::area_in_hp+37>::area_in_hp+37>: movq
$0x8,0x10(%rsp)
0xffffffffc07fe03e <rust_panic::area_in_hp+46>::area_in_hp+46>: movq
$0x0,0x18(%rsp)
0xffffffffc07fe047 <rust_panic::area_in_hp+55>::area_in_hp+55>: mov
%rsp,%rcx
0xffffffffc07fe04a <rust_panic::area_in_hp+58>::area_in_hp+58>: mov
$0xc,%edx
0xffffffffc07fe04f <rust_panic::area_in_hp+63>::area_in_hp+63>: mov
$0xffffffff96afb62c,%rdi
0xffffffffc07fe056 <rust_panic::area_in_hp+70>::area_in_hp+70>: mov
$0xffffffffc0bd5118,%rsi
0xffffffffc07fe05d <rust_panic::area_in_hp+77>::area_in_hp+77>: call
0xffffffff95fcb2e0 <kernel::print::call_printk>
0xffffffffc07fe062 <rust_panic::area_in_hp+82>::area_in_hp+82>: movq
$0xffffffffc0bd50d0,0x30(%rsp)
...
crash> gdb bt
#0 0xffffffff958db684 in crash_setup_regs (newregs=0xffffd08c4f063a48, oldregs=0x0) at
./arch/x86/include/asm/kexec.h:108
#1 0xffffffff958db711 in __crash_kexec (regs=regs@entry=0x0) at
kernel/crash_core.c:122
#2 0xffffffff9560cede in panic (fmt=<optimized out>) at kernel/panic.c:401
#3 0xffffffffc07fe107 in rust_panic::HelloPanic::trigger_panic (self=0x1) at
rust_panic.rs:59
#4 rust_panic::HelloPanic::step_three (self=0x1) at rust_panic.rs:53
#5 rust_panic::area_in_hp (rectangle=0xffffd08c4f063c38) at rust_panic.rs:24
#6 0xffffffffc07fe160 in rust_panic::HelloPanic::step_two (self=<optimized out>)
at rust_panic.rs:46
#7 0xffffffffc0c5d067 in ?? ()
crash> frame 5
#5 rust_panic::area_in_hp (rectangle=0xffffd08c4f063c38) at rust_panic.rs:24
24 in rust_panic.rs
crash> whatis rectangle
*mut rust_panic::RectangleHP
crash> p *rectangle
$2 = rust_panic::RectangleHP {
width: 30,
height: 50
}
crash> struct RectangleHP
struct rust_panic::RectangleHP {
width: u32,
height: u32,
}
SIZE: 8
crash>
Anyway, there are still many limitations of debugging complex, nested
data type about Rust code in kernel. I do not expect patches to always
work well in the real world, but it can get improved over time. As you
know, also some challenges come from the compilers, they may have
different behavior, for example:
crash> gdb bt
#0 rust_helper_BUG () at rust/helpers/bug.c:7
#1 0xffffffff98b5a92a in kernel::panic (info=0xffffcf05880d7800) at
rust/kernel/lib.rs:202
#2 0xffffffff9840e310 in core::panicking::panic_fmt (fmt=...) at
/home/llvm-20.1.8-rust-1.88.0-x86_64/lib/rustlib/src/rust/library/core/src/panicking.rs:75
#3 0xffffffffc12e71ec in ?? ()
#4 0xffffcf05880d7880 in ?? ()
#5 0xffffffffc14680a8 in ?? ()
crash>
Note: The above kernel is compiled with the clang(clang version 20.1.8
(https://github.com/llvm/llvm-project.git 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)), the
gdb stack unwind looks incomplete.
BTW: I did not see the similar issues on the kernel that compiled by the gcc (GCC)
14.3.1.
Note: the rust_panic is a Rust kernel module, which is used to test the
current patchset. If anyone needs it, I can share it via email.
Lianbo Jiang (3):
Add a rustfilt command to demangle a mangled Rust symbol
Enable demangling a mangled Rust support
Enable resolving mangled Rust symbol in lockless ring buffer
Makefile | 2 +-
defs.h | 2 ++
global_data.c | 1 +
help.c | 10 +++++++
printk.c | 28 +++++++++++++++++-
symbols.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 119 insertions(+), 2 deletions(-)
--
2.50.1