BUG? no symbol at address <xyz>

[matejcik]

Analyzing an example built from a stm32f4 project. It requires linking to a C library, which I mocked out by declaring void symbol_name_here(void) {} for every needed symbol (because the real thing links the other way, using the crate as a staticlib -- and my attempts to make Rust link everything correctly have failed). So that could plausibly have something to do with it.

cargo +nightly call-stack --example ex --features=... --target=thumbv7em-none-eabihf returns:

thread 'main' panicked at 'BUG? no symbol at address 146572', /Users/matejcik/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-call-stack-0.1.11/src/main.rs:970:48
stack backtrace:
   0: rust_begin_unwind
             at /rustc/263edd43c5255084292329423c61a9d69715ebfa/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/263edd43c5255084292329423c61a9d69715ebfa/library/core/src/panicking.rs:142:14
   2: cargo_call_stack::run::{{closure}}
   3: cargo_call_stack::run
   4: cargo_call_stack::main

binary is here: https://easyupload.io/dj57kq
output of objdump -D is here: https://pastebin.mozilla.org/E4DoW44B

it appears that there is indeed no symbol at address 146572, or 0x23c8c:

00023c54 <_ZN4core3str19slice_error_fail_rt17h8803d315cd910966E>:
(...)
   23c86:	2401      	movgt	r4, #1
   23c88:	f104 0cfd 	add.w	ip, r4, #253	; 0xfd
   23c8c:	f910 400c 	ldrsb.w	r4, [r0, ip]
   23c90:	f114 0f41 	cmn.w	r4, #65	; 0x41
(...)

i can do more debugging if you give me some pointers, at this point I have zero idea where to start.

[japaric]

thanks for the bug report. that panicking branch is part of the analysis of the ARM (Thumb) assembly in the ELF file. I guess that there's some bug in cargo-call-stack's disassembler and it's computing a wrong offset for either a b (branch) or bl (branch-link) instruction.

as cargo-call-stack works on source code (Cargo projects) rather than ELF files, it would be hard for me to look deeper into this. if you want to investigate further, I would suggest logging the name of each function analyzed

cargo-call-stack/src/main.rs

Line 830 in 7d0b16e

let canonical_name = aliases[&sym.names()[0]];

as well as the base address and the offset of each bl instruction

cargo-call-stack/src/main.rs

Line 947 in 7d0b16e

for offset in bls {

and of each b instruction found

cargo-call-stack/src/main.rs

Line 961 in 7d0b16e

for offset in bs {

the trace should hopefully point to the function - instruction pair that causes the panic