dankeboy36
commented
12 months ago Thank you for the feature request.
if you have already looked into implementing exception decoding for RISC-V chips, such as ESP32-C3?
No, I have not.
I found one mention of C3 in the tests
Great that you have looked into the code. :pray:
but it seems that the code required to convert ESP32-C3 register+stack dumps into backtraces is missing.
The tests cover the correctness of the gdb path lookup based on the FQBN. The decoding logic needs to be implemented.
Do you have something like that in progress,
No, I do not have anything.
do you plan on implementing this,
Of course, why not? Great idea.
or would you like anyone from Espressif to open a PR with this implementation?
I always appreciate any help you can give me.
I am neither a domain expert nor programming Arduino boards; I enjoy writing tooling and understand the Arduino ecosystem well, so any technical pointer, as you gave above, is welcome.
If you plan to contribute, developing a working prototype is sufficient, and I can help finalize the code. Please let me know if you decide so.
Otherwise, I am also happy to understand how it works and reimplement it, but it will be available later as I have other priorities. Also, I need to order a C3 board and look into the Python code. So please bear with me if you decide to wait.
I would be happy to have this new feature in the repository.
majodi
per1234
Hi @dankeboy36, thanks a lot for effort you put into making this incredibly useful plugin! I would like to check if you have already looked into implementing exception decoding for RISC-V chips, such as ESP32-C3? I found one mention of C3 in the tests but it seems that the code required to convert ESP32-C3 register+stack dumps into backtraces is missing.
Do you have something like that in progress, do you plan on implementing this, or would you like anyone from Espressif to open a PR with this implementation?
For reference: on RISC-V chips, by default we can only dump the registers and the stack, not the backtrace. Unwinding the stack to produce the backtrace on the chip itself is not possible, unless CONFIG_ESP_SYSTEM_USE_EH_FRAME option is enabled. (It is disabled by default, since it significantly increases application binary size.)
To perform stack unwinding, a tool running on the host PC is required. In ESP-IDF, this is done using gdb_panic_server.py which acts as a GDB server. GDB is launched, it connects to the script acting as a server, the script feeds GDB information from the stack dump as if it was coming from the real target, and finally GDB decodes the backtrace (code here).
This is slightly more complex than decoding backtraces on Xtensa chips, but since we already have access to GDB in this plugin, looks like this should be doable.