-
-
Notifications
You must be signed in to change notification settings - Fork 595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
esp32_exception_decoder: ESP32-C3 support; possibility for external configuration #612
Conversation
Hi @Tasssadar ! Any chance you could take a look at this PR? Thanks in advance! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, great work, thanks :)
Can you show us some screenshots how it looks like with ESP C3 and the normal stack trace from base ESP32?
Also, does the addr2line from rust have the same text output as the one from gcc? Might break the parsing in this filter.
Nope it is not a great work, unfortunately. First of all, on C3 they are producing not a backtrace, but stack dump it seems, which is then post-processed with GDB to get the actual "backtrace". If we don't do this as well in this filter (i.e. call GDB to get just the backtrace from the stack dump), I'm afraid we'll get decodings that simply do not belong to the backtrace and are there as left overs from previous calls. (To make the rabbit hole even deeper, I'm seeing these fake things even on stock ESP32 with regular "backtrace" output, so this has to be checked as well - might be something Rust specific, related to calling conventions, etc.) So what I would suggest is - I'll have to dig deeper first, and probably even talk to Espressif developers to see what the future plan is. They might be switching to "stack dumps" even on the Xtensa chips. In the meantime, we should either close this PR (I'll open another one when I have some more visibility as to what is going on and what the overall plan is) or to turn this into draft. |
(re addr2line - the Rust toolchain is currently using the addr2line from GCC, as well as the linker from GCC. ESP-IDF itself is compiled with GCC, while the rust code is obviously compiled with Rust. They are linked then with GCC->LD) |
@ivmarkov FWIW, I noticed the missing backtrace on ESP32-C3/RISC-V too when adding support to ESPHome a while back: You can "safely" decode the PC and LR to get at least the current function and the function before that (minus inlines, of course). Maybe this is start. I think this is a limitation of the toolchain and/or ESP-IDF's exception handling which cannot make sense of the stack currently and hence print a useable Backtrace. |
It is a RiscV-specific limitation in that the code on the ESP32-C3 is compiled without FP (frame pointer support), and therefore the stack trace cannot be reconstructed.
More info here: esp-rs/rust#76 (comment) |
self.project_strip_dir = os.environ.get("esp32_exception_decoder_project_strip_dir") | ||
self.firmware_path = os.environ.get("esp32_exception_decoder_firmware_path") | ||
self.addr2line_path = os.environ.get("esp32_exception_decoder_addr2line_path") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do mean these hacks?
@Tasssadar, sorry that disturb you. Does Espressif have an official decoder which can reuse without reinventing the wheels? |
It had been more than 6 months, and in the meantime things have changed a bit:
EDIT: More than 6 months, not an year, but a long time anyway :) |
in documentation https://docs.platformio.org/en/latest/core/userguide/device/cmd_monitor.html#filters esp32_exception_decoder I found "Custom filter for Espressif 32 which decodes crash exception" so I understand it works for ESP32 -C3 too. |
I can confirm it does not wirk with ESP32C3 for me, neither. |
Up ? |
Dear all,
This PR is implementing the following set of changes to the
filter_exception_decoder.py
(a.k.a.esp32_exception_decoder
filter):(Most important) Support for ESP32-C3 (and future RiscV based chips)
Backtrace:
string prefix (these start with aStack memory:\n\n
string prefix instead and overall have a very different and much more verbose dump of hexadecimal integers)0x4xxxxxxx
instead, as this is an indication of a memory address which is corresponding to a code location. While this results in hexadecimals outside of the stacktrace being decoded as program locations, it is (a) more robust and (b) it has the nice benefit precisely that PC counters anywhere in the log will be decoded. I.e. we are planning to dump backtraces on non-panic situations from our Rust code, so this type of decoding will decode these backtraces tooAs a consequence, the decoded output is served on a separate line (or lines) following the line where PC counter address (or addresses) were detected. Looks quite OK IMO
The decoded output is colored (with an ANSI sequence) in yellow, for better visibility. ESP-IDF logging uses ANSI sequences by default too
Finally (but important for us) I've put provisions in the code to to take the firmware location,
addr2line
location and the project location via environment variables, as this is necessary for our Rust support (PlatformIO is used there as a build-support utility, but is not driving the whole build process, which is orchestrated by Rust Cargo). If these environment variables are not set, the filter will fall back to the standard logic of locating these items based on PlatformIO APIs.