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