[resolved] Use crate name as first part of a symbol's name

internals
1

Having the crate name in every symbol would be a good way to enhance understandability of backtraces and especially profiling / debugging tools.

A symbol name like examplepanic::inner::call_me is more understandable than inner::call_me, especially when it is not your own crate, and the inner module is an implementation detail.

Is this a reasonable idea? Is there a drawback to adding to the length of every symbol?

Example backtrace now, compared with proposed below:

thread '<main>' panicked at 'assertion failed: `(left == right)` (left: `1`, right: `2`)', examplepanic.rs:4
stack backtrace:
   1:     0x55ae2c892730 - sys::backtrace::tracing::imp::write::hf58fd64f7eba8fa9Gxu
   2:     0x55ae2c89486b - panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::closure.45009
   3:     0x55ae2c894503 - panicking::default_hook::h651531e1570ee8a6xJz
   4:     0x55ae2c88ed9f - sys_common::unwind::begin_unwind_inner::hf07bbad5568749aa2ot
   5:     0x55ae2c88f3c8 - sys_common::unwind::begin_unwind_fmt::hb1c014139c1c243d8nt
   6:     0x55ae2c88e31c - inner::call_me::h7f81b684393a7f3bgaa
   7:     0x55ae2c88e175 - main::hfca0b16e9aeb09a8Bba
   8:     0x55ae2c894184 - sys_common::unwind::try::try_fn::h16746780088530188840
   9:     0x55ae2c891b9b - __rust_try
  10:     0x55ae2c893c1b - rt::lang_start::h49952a17d840245dKBz
  11:     0x55ae2c88e359 - main
  12:     0x7f313f17260f - __libc_start_main
  13:     0x55ae2c88e068 - _start
  14:                0x0 - <unknown>

If we had crate names as the first part it could for example look like this (the panic is in my crate called examplepanic).

thread '<main>' panicked at 'assertion failed: `(left == right)` (left: `1`, right: `2`)', examplepanic.rs:4
stack backtrace:
   1:     0x55ae2c892730 - std::sys::backtrace::tracing::imp::write::hf58fd64f7eba8fa9Gxu
   2:     0x55ae2c89486b - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::closure.45009
   3:     0x55ae2c894503 - std::panicking::default_hook::h651531e1570ee8a6xJz
   4:     0x55ae2c88ed9f - std::sys_common::unwind::begin_unwind_inner::hf07bbad5568749aa2ot
   5:     0x55ae2c88f3c8 - std::sys_common::unwind::begin_unwind_fmt::hb1c014139c1c243d8nt
   6:     0x55ae2c88e31c - examplepanic::inner::call_me::h7f81b684393a7f3bgaa
   7:     0x55ae2c88e175 - examplepanic::main::hfca0b16e9aeb09a8Bba
   8:     0x55ae2c894184 - std::sys_common::unwind::try::try_fn::h16746780088530188840
   9:     0x55ae2c891b9b - __rust_try
  10:     0x55ae2c893c1b - std::rt::lang_start::h49952a17d840245dKBz
  11:     0x55ae2c88e359 - main
  12:     0x7f313f17260f - __libc_start_main
  13:     0x55ae2c88e068 - _start
  14:                0x0 - <unknown>
2 Likes
2

rustc developers think of everything. They even thought to implement & merge the idea 13 hours before it was requested! https://github.com/rust-lang/rust/pull/32293

9 Likes
3

Dang, that’s pretty cool.

Speaking of implementing things before they are asked for, I was trying to write a kernel driver in Rust. I did get a simple rot13 driver working, but trying to do anything that required accessing the structs from Rust was pretty much impossible due to all the ifdefs and massive size of structs in the kernel. I tried to port on manually, and was off by some 12 bytes in size somehow. I gave a short talk on my experience, and said it was basically impossible to write a kernel drived since bindgen doesn’t work on the kernel, but while I was giving the talk, someone pushed a PR on github getting bindgen to work with the kernel

It was amazing. Open source is really nice when problems get solved for you.

2 Likes
4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.