Hello,

started using this crate today after it got pulled in by the no_std application template. I see that currently it just debug-prints the PanicInfo, but would you accept a PR that adds some prettier formatting around it?

In a minimal esp32 code that prints "Hello" and then panics, the serial output is pretty crowded imo:

load:0x3fff0054,len:4800
load:0x40078000 [_stack_end_cpu0:??:??],len:17448
load:0x4007c428 [_stack_end_cpu0:??:??],len:4840
entry 0x4007c6a0 [_stack_end_cpu0:??:??]
Hello
PanicInfo { payload: Any { .. }, message: Some(Help me, I'm dying!), location: Location { file: "src/main.rs", line: 30, col: 9 }, can_unwind: true }
0x400d1bb8 [half_duplex_uart::__xtensa_lx_rt_main:/var/home/ahartmann/repos/mt/playground/half-duplex-uart/src/main.rs:30]
0x400d5816 [Reset:/usr/local/share/cargo/registry/src/github.com-1ecc6299db9ec823/xtensa-lx-rt-0.13.0/src/lib.rs:77]
0x400d29af [ESP32Reset:/usr/local/share/cargo/git/checkouts/esp-hal-42ec44e8c6943228/6e037b0/esp32-hal/src/lib.rs:78]

I was thinking about maybe something like this:

load:0x3fff0054,len:4800
load:0x40078000 [_stack_end_cpu0:??:??],len:17448
load:0x4007c428 [_stack_end_cpu0:??:??],len:4840
entry 0x4007c6a0 [_stack_end_cpu0:??:??]
Hello

!! A panic occured at "src/main.rs", line 30, column 9

  Message: Help me, I'm dying!
  Payload: ??
Backtrace:

0x400d1bb8 [half_duplex_uart::__xtensa_lx_rt_main:/var/home/ahartmann/repos/mt/playground/half-duplex-uart/src/main.rs:30]
0x400d5816 [Reset:/usr/local/share/cargo/registry/src/github.com-1ecc6299db9ec823/xtensa-lx-rt-0.13.0/src/lib.rs:77]
0x400d29af [ESP32Reset:/usr/local/share/cargo/git/checkouts/esp-hal-42ec44e8c6943228/6e037b0/esp32-hal/src/lib.rs:78]

Or in accordance with the default rust panic handler:

!! A panic occured at src/main.rs:30:9

instead of relying solely on the Debug trait for printing. Also add some more space to the output, so the Panic is easily recognized between application text and the backtrace.

Currently, accessing the panic message is an unstable feature in core, see this tracking issue: https://github.com/rust-lang/rust/issues/66745

So unless this lands, the current debug print actually contains more useful information than this PR...

In order to prepare a small change in esp-hal ( https://github.com/esp-rs/xtensa-lx-rt/pull/50 ) we first need to update all its dependencies

When this is merged, we need to bump this crate's version and release it

In https://github.com/esp-rs/esp-hal/pull/207 the trap frame struct changed. We should adapt our copy of the trap frame struct here.

Nothing bad should happen if we keep it like this so it's not an urgent task

I figured out how to accomplish this, so here it is. The RISC-V job looks a little strange due to only having one chip, but once esp-println has a new release I will be PRing ESP32-C2 support here.

Doesn't cover every possible combination, but much better than nothing.

Successful run here:
https://github.com/jessebraham/esp-backtrace/actions/runs/2890318205

To make backtraces work on RISCV the user needs to force frame-pointers. We can give a hint in case there are no backtrace entries when running on a RISCV target instead of printing nothing

Keeping this as a draft until esp-println has a new release, but the work is otherwise done. I added some comments for the features and updated our build script to match esp-println as well.

Closes #12 Closes #13

In line with the print-uart and print-rtt features, perhaps a print-defmt would make sense?

I am happy to submit a PR for this, however I have a question. The current implementation calls several println!() functions. In most defmt log printers, the contents of the log statement gets printed along with the location in the source code that the log statement was called.

Would this mean that we would have only one error!() invocation in the panic_handler? Or should we still call error!() each time we call println().

Also, due to this quirk of defmt vs println style printing, should I add this functionality to esp-println? Because it may be a mismatch of expected output format.

The stack walking code isn't specific to esp's, only the printing methods. This crate maybe useful to other chip vendors if we had a custom printing feature.

This isn't something we'll implement but maybe a good contribution from the community :).