backtrace (of rust code) is incomplete on esp32c6 #275
Comments
Experiment 1: Add
|
Experiment 2: Add
|
Experiment 3: Set
|
Experiment 4: Enable DWARF by setting
|
ConclusionComing from esp-hal, I find the backtraces on esp-idf-sys extremely painful to handle. They contain a lot of noise, and unless i enable DWARF generation, they will not contain any of my functions in question or only some of them. Surely there must be a way to get a clear and concise backtrace? How can we improve the situation? When printing with esp_backtrace, why dont I see my rust functions a,b and c, when using esp-idf-sys instead of esp-hal. Have my frame pointers suddenly disappeared? Thank you! |
|
Your original experiment, in the original issue report:
This is because the panic output from ESP IDF contains a stack memory dump, that - unluckily - is not formatted with regular byte-oriented hexdump i.e. My guess is that |
I don't have explanation for that. That's weird, because from LLVM's POV, the two targets look exactly the same.
Sure. As per above, espflash crawls though the stack memory and blindly applies decoding to everything which looks like a 32 bit word. Including to stuff which is is definitely not an IP (instruction pointer), but data. Suggestion for improvement: the noise might get reduced if the decoding is applied by |
There IS a difference! :) Snippet from experiment 2: Snippet from experiment 3: Where originally it used to say now it says:
|
Another idea could be to run GDB (if installed) and actually decode the backtrace based on the stack and the registers, like https://github.com/espressif/esp-idf-panic-decoder/blob/master/esp_idf_panic_decoder/gdb_panic_server.py does. |
Aaah, good catch. 🎉 Experiment 1bInstead of using and then invoke esp_backtrace in as a panic hook.
fn c() {
panic!("oh no");
}
fn b() {
c();
}
fn a() {
b();
}
fn main() {
esp_idf_svc::sys::link_patches();
esp_idf_svc::log::EspLogger::initialize_default();
std::panic::set_hook(Box::new(|info| {
println!("panic occurred: {:?}", info);
let bt = esp_backtrace::arch::backtrace();
for a in bt {
if let Some(a) = a {
println!("esp_backtrace: 0x{:x}", a);
}
}
}));
a();
}espflash now outputs: Full espflash enhanced output |
For me, this works. The output from |
Let's unpack this a bit for the sake of being precise:
Let's put the "noisiness" problem aside for the moment. 1. DWARF based (solved for me)
Action item: document this approach better somewhere 2. riscv frame-pointer based
Action item: We can try to upstream the 3. GDB decoding of the memory stack frame
Action item: Work on the first or second option
Different optimization settings, as per above? The noisiness problemI think we should postpone this for a while, until we figure out whether we need to concentrate on (2) or (3). |
|
Oops. I was a bit too eagerly creating esp-rs/espflash#543, seeing your conclusion here ^^. Can you take over, and create the remaining issues/tasks based on your action items? |
i think for gdb and stuff as long as you are not talking about the gdb-stub over uart rather connecting external gdb server, we already have a working solution with |
No it is not gdb-over-uart. It is about (ab)using GDB to do the stack walking for us when presented with Basically, we have to either find a way to run this script and the ESP IDF monitor in general |
|
And given that the whole stack memory + registers' dump is so ESP IDF specific, perhaps it would be easier and more natural to just find a way to call Which brings back the question/trick from some time ago which is that we have to have at least one successful build of |
I think we can keep it simple and have just this task/issue for now. I would only create a separate task for the documentation of the DWARF "trick" in the Rust ESP book. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm trying to obtain a backtrace for a simple rust program when it panics.
Code:
I'm using the esp32c6 here, together with
espflash run --monitor.I have found that the amount of info I can get from the backtrace varies a lot when using
esp-idf-syscompared to when usingesp-hal.rust --version -v:esp-hal // no_std Case
Based on
cargo generate esp-rs/esp-templateI have the following setup.main.rs:Cargo.toml:`.cargo/config.toml`: As generated by the template
Invocation:
cargo runespflash enhanced output:
esp-idf-sys/ std Case
Based on
cargo generate esp-rs/esp-idf-templateI have the following setup.main.rs:`Cargo.toml`: As generated by the template
.cargo/config.toml:esp-idf version:
v5.3-dev-422-ga7fbf452fasdkconfig-defaults:Invocation:
cargo runraw output(serial port monitor, without esp flash):
`espflash run --monitor` enhanced output: contains main, but neither a, b or c and is really verbose
Conclusion / Summary
The output of the esp-idf-version does not contain any of my functions (a,b,c). It does contain main, buried under a lot of noise.
I dont care a lot about the noise, but I would really like to see my functions (a,b,c).
The text was updated successfully, but these errors were encountered: