search

knurling-rs / probe-run

Run embedded programs just like native ones
Apache License 2.0
644 stars 75 forks source link

`release/debug=false` works but `dev/debug=false` doesn't #9

Open japaric opened 4 years ago

japaric commented 4 years ago

If release works then dev should also work.

STR: with defmt's log example (all the other examples produce similar errors)

$ # dev/debug=false
$ cargo run --bin log
(..)
stack backtrace:
   0: 0x00000bec - __bkpt
   1: 0x00000632 - log::__cortex_m_rt_main
   2: 0x000002d6 - main
   3: 0x0000261a - Reset
Error: debug information is missing. Likely fixes:
1. compile the Rust code with `debug = 1` or higher. This is configured in the `profile.*` section of Cargo.toml
2. use a recent version of the `cortex-m` crates (e.g. cortex-m 0.6.3 or newer). Check versions in Cargo.lock
3. if linking to C code, compile the C code with the `-g` flag

Caused by:
    Do not have unwind info for the given address.

$ # release/debug=false
$ cargo run --release --bin log
stack backtrace:
   0: 0x00000974 - __bkpt
   1: 0x0000080e - log::__cortex_m_rt_main
   2: 0x00000108 - main
   3: 0x000008c2 - Reset

$ # dev/debug=true
$ cargo run --bin log
stack backtrace:
   0: 0x00000ede - __bkpt
   1: 0x000009ea - log::__cortex_m_rt_main
   2: 0x0000065c - main
   3: 0x00002b2a - Reset
jonas-schievink commented 4 years ago

It looks like the backtrace crate (and thus libstd) do still use libunwind to unwind the stack, just symbolication is done with gimli. So that explains why it works there even without debuginfo.

jonas-schievink commented 4 years ago

It actually looks like there simply isn't any DWARF data for certain functions when setting debug = false. My current assumption is that this means that unwinding is trivial (ie. just follow LR), and that seems to hold up in practice so far, except that we cannot detect the end of the stack properly since 0xFFFFFFFF never ends up in LR this way.

japaric commented 4 years ago

Hitting this with the LPC845. I get roughly the same output using both the dev and release profile:

stack backtrace:
   0: 0x000002f0 - __bkpt
   1: 0x000002e4 - my_app::exit
   2: 0x00000160 - hello::__cortex_m_rt_main
   3: 0x000000c8 - main
   4: 0x000001a2 - Reset
   5: 0x0f0002e4 - <unknown>

It seems the unwinder is going beyond the zero-th stack frame. It could be that this particular hardware (Cortex-M0+) initializes the LR register on reset to the value 0x0f0002e4? If that's the case perhaps we could have probe-run set LR to 0xFFFFFFFF after flash+reset-ing the device (there should be some API to reset and halt right after reset)

japaric commented 3 years ago

ran into this issue today while running cargo test. This error path makes probe-run exit with a non-zero code so this bug is making cargo test fail even though 'all tests passed' was printed. Will investigate more tomorrow.