Open japaric opened 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.
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.
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)
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.
If release works then dev should also work.
STR: with
defmt
's log example (all the other examples produce similar errors)