How to get backtrace showing in panics?

[yanshay]

In the past I recall seeing backtraces when my code or some library code triggered a panic.
Now I don't and I need it to troubleshoot some issue.

These are the pieces I found as relevant to this and have in my code, but it still doesn't work:

In cargo.toml I have:

esp-backtrace = { version = "0.14.0", features = [
    "panic-handler",
    "println",
    "exception-handler",
] }

In config.toml for my esp32s3 I have:

[target.xtensa-esp32s3-none-elf]
runner = "espflash flash --monitor --baud 921600 --partition-table ./partitions.csv"

rustflags = [
  "-C", "link-arg=-Tlinkall.x",
  "-C", "link-arg=-nostartfiles",
  "-C", "link-arg=-Trom_functions.x",
  "-C", "force-frame-pointers",
]

In main.rs I have:

use esp_backtrace as _;

[bjoernQ]

On Xtensa "-C", "force-frame-pointers", is not necessary but shouldn't hurt. Can you post a minimal-repro?

e.g. this

#![no_std]
#![no_main]

use core::fmt::Write;

use esp_backtrace as _;
use esp_hal::{delay::Delay, prelude::*};
use esp_println::println;

#[entry]
fn main() -> ! {
    let _peripherals = esp_hal::init(esp_hal::Config::default());
    let delay = Delay::new();

    loop {
        println!("Hello World!");
        delay.delay(1.secs());
        foo();
    }
}

#[inline(never)]
fn foo() {
    bar();
}

#[inline(never)]
fn bar() {
    baz();
}

#[inline(never)]
fn baz() {
    panic!("oh no");
}

Produces this

====================== PANIC ======================
panicked at src\bin\hello_world.rs:45:5:
oh no

Backtrace:

0x42000586
0x42000586 - hello_world::bar
    at C:\projects\clean\esp-hal\examples\src\bin\hello_world.rs:40
0x4200057a
0x4200057a - hello_world::foo
    at C:\projects\clean\esp-hal\examples\src\bin\hello_world.rs:35
0x420005e8
0x420005e8 - hello_world::__xtensa_lx_rt_main
    at C:\projects\clean\esp-hal\examples\src\bin\hello_world.rs:29
0x4200484e
0x4200484e - Reset
    at C:\projects\clean\esp-hal\xtensa-lx-rt\src\lib.rs:82
0x40378d88
0x40378d88 - ESP32Reset
    at C:\projects\clean\esp-hal\esp-hal\src\soc\esp32s3\mod.rs:155

[yanshay]

I tracked it down to not having lto = 'fat' under [profile.release] in cargo.toml.

I don't really understand what that means and why I had lto=false in my project, but that's the thing.
At some point I probably copied it from some example somewhere.

But if I get it right, lto is about link time optimization, so shouldn't affect functionality, should it?

What's the recommended [profile.release]? The one in the examples cargo.toml?

[MabezDev]

Yes, the recommended for performance and general usability is the one in examples Cargo.toml.

[yanshay]

I think I don't get the full backtrace. This is the exception I face:

panicked at /Users/my_user/.cargo/git/checkouts/slint-8153123e5dffa129/746100b/internal/core/timers.rs:257:13:
Recursion in timer code

Backtrace:

0x42060dc6
0x42060dc6 - i_slint_core::platform::update_timers_and_animations
    at /Users/my_user/.cargo/git/checkouts/slint-8153123e5dffa129/746100b/internal/core/platform.rs:236
0x420c3d29
0x420c3d29 - <i_slint_core::window::WindowRedrawTracker as i_slint_core::properties::PropertyDirtyHandler>::notify
    at /Users/my_user/.cargo/git/checkouts/slint-8153123e5dffa129/746100b/internal/core/window.rs:367
0x420bb9a9
0x420bb9a9 - i_slint_core::properties::mark_dependencies_dirty::{{closure}}
    at /Users/my_user/.cargo/git/checkouts/slint-8153123e5dffa129/746100b/internal/core/properties.rs:721
0x420bb9c1
0x420bb9c1 - i_slint_core::properties::dependency_tracker::DependencyListHead<T>::for_each
    at /Users/my_user/.cargo/git/checkouts/slint-8153123e5dffa129/746100b/internal/core/properties.rs:195

Since it's embassy and my code that drives everything I'd expect to see my code (or embassy as starting point) somewhere in the backtrace and I don't.
I saw there's a limit of 10 addressed in esp-backtrace but here I see only 4, so it's not that limit.

Could it be that some of the modules are not included or something else?

[MabezDev]

Optimization levels will reduce debugability, you can try lowering the opt-level, but this may introduce other issues (for example esp-wifi needs higher levels of opt to function correctly). The best way to debug something is with a probe and a debugger, using openocd/gdb or probe-rs, the backtrace is on a best effort basis.