Can it run with another elf file?

[hitecSmartHome]

With the previous exception decoder you could select the .elf file before it decodes. Can it be selected with this as well?

[dankeboy36]

Thank you for submitting the proposal.

I am aware that the original implementation has this capability, and I made it possible to specify an elf file path manually in the code, but I have never exposed this functionality to the UI.

The original implementation derives information for decoding from the boards.txt and platform.txt files, while this new implementation is based on the Arduino CLI's compile output. I have not been able to identify a compelling use case for implementing this feature, as the selected elf file and the CLI's compile output can quickly become out of sync. Additionally, I do not have the capacity to support such GitHub issues. Could you provide a specific use case for this feature? If it is reasonable, I can consider implementing it.

Please describe the scenario in which you envision using this feature. For instance, if I open IDE2 and load the previous Blink sketch, the IDE restores my previous board and port selection. Let's say an AVR Uno board has been selected (which is not supported by this extension), and the user clicks on the decode extension and selects the elf file; what should happen, or where would the stack trace come from? Adding an open file dialog action is relatively easy, but it's unclear what issue it resolves.

Thank you!

[hitecSmartHome]

Thank you for your response!

The use case for me and for a lot of other folks out there is that we don't use the Arduino IDE at all. In the past year I only opened the Arduino IDE ( 1 ) purely for decoding stack traces. I'm using Visual Studio Code for developing, mainly the PlatformIO IDE. This has the capability to catch and decode expections if your Serial monitor is open but in a lot of other cases we use Putty or other Serial terminal to monitor the esp32. In this case, since Putty and other terminals does not have this decoding capability, we only see the raw stack trace.

What I do right now is that I copy the raw stack trace from the terminal into the Arduino IDE, select the ELF file from my project which is in a totally different place than Arduino IDE and decode it.

When I open the Arduino IDE and select ESP Expection Decoder in the tools, it automatically opens up the windows file manager so I can search and select the ELF file I want. This is really good because I don't rely on any IDE or any compiler, just the raw ELF file.

The best thing would be to make the decoder into a standalone application instead of an Arduino IDE tool so anyone could use it without the IDE dependency. This way it could be integrated into any workflow and make it more robust.

For example it would be benefical to decode Core Dumps generated by IDF on crash. My application reads the Core Dump partition on boot if it was crashed the last time and I can download this data as a file. After I can open the ESP-IDF 5.2 PowerShell, cd into my project dir and run this command to decode the stack trace: esp-coredump.exe --gdb-timeout-sec 10 info_corefile -c .\CoreDump\coreDump.bin -t raw .\CoreDump\firmware.elf In order for this to work, I have to download the Core Dump data from the esp32, and place it into a separate directory along with the ELF file for decoding. This process is really long and uncomfortable.

Since there is no standalone decoder application and every version is integrated into an existing IDE or into some other program, of course I don't expect from you or from anyone else to do it since it satisfies almost every use case right now. I'm just saying that it would be really cool if this tool could select any ELF file and do not rely on the Arduino IDE's compilation pattern.

Thank you very much for reading!

[per1234]

The best thing would be to make the decoder into a standalone application instead of an Arduino IDE tool

You can find several standalone exception decoder tools listed in the threads on these issues in the Arduino IDE 1.x tool's repo:

• https://github.com/me-no-dev/EspExceptionDecoder/issues/8
• https://github.com/me-no-dev/EspExceptionDecoder/issues/87

[hitecSmartHome]

@per1234 Thank you very much for the links. Will check them out!

[dankeboy36]

I am open to the idea of extracting the decoder logic into a standalone command-line interface, but I do not plan to implement this feature within the decoder extension.

I see a few concerns regarding a new CLI:

1. There is already an existing one. (https://github.com/dankeboy36/esp-exception-decoder/issues/27#issuecomment-2358179108)
2. The CLI will be written in Node.js, and I do not expect users to install Node.js just to use the CLI. Therefore, Node.js will need to be packaged into a single executable. The executable will be >150MB.
3. Application notarization for macOS requires a membership in the Apple Developer Program.

The topic of the command-line interface is open for discussion. Please use this issue to share your input.

---

Proposal for the TraceBreaker (trbr) CLI

trbr [OPTIONS] <toolPath> <elfPath>

Command Structure

• toolPath (required) – Filesystem path to the GDB tool.
• elfPath (required) – ELF file for decoding stack traces.

Options

Option	Description
--riscv	Switch to RISC-V decoder mode
--file <path>	Read input from a file instead of stdin
--version	Print version information and exit
-v	Enable verbose mode
-vv	Enable very verbose mode
--no-color	Disable ANSI coloring

Modes of Operation

trbr can run in two modes:

1. Interactive Mode (The terminal is in full-screen mode)

   • Reads stack traces from stdin (via | or <() redirection).
   • Allows the user to paste stack traces manually to process.

2. File Mode (--file <path>)

   • Reads stack traces from a file instead of stdin.

Example Usage

1. Interactive Mode (stdin)

Using piped input from another command:

serial_monitor | trbr /path/to/gdb /path/to/firmware.elf

Using process substitution:

trbr /path/to/gdb /path/to/firmware.elf <(less)

Pasting input manually:

trbr /path/to/gdb /path/to/firmware.elf

2. File Mode

Provides the input from a file:

trbr /path/to/gdb /path/to/firmware.elf --file trace.log

---

3. Other

Use the --riscv flag to switch to RISC-V mode:

trbr /path/to/gdb /path/to/firmware.elf --riscv

👆, the current exception decoder extension can infer this info from the FQBN of the board, but users should control it with this lower-level CLI.

--verbose mode

trbr /path/to/gdb /path/to/firmware.elf -v

--very-verbose mode

trbr /path/to/gdb /path/to/firmware.elf -vv

--no-color to disable ANSI coloring

trbr /path/to/gdb /path/to/firmware.elf --no-color

[dankeboy36]

From https://github.com/dankeboy36/esp-exception-decoder/issues/6#issuecomment-2693357164:

Also: Can we use this with a stacktrace for a custom ELF file? In order to investigate production issues logged on previous releases?

In order to investigate production issues logged on previous releases?

@dirkvranckaert, can you please explain your use case more?

[per1234]

Application notarization for macOS requires a membership in the Apple Developer Program.

I have a membership that I plan to keep active for the foreseeable future. I am happy to allow the notarization to be done via my Apple Developer account if that would be helpful.

[dirkvranckaert]

@dankeboy36 I'm collecting 'stacktraces' from ESP's in production. For every version in production that we release we collect / keep the ELF file. What I would like to be able (as we are able with the ESP8266) is to decode a stacktrace with a 'custom' ELF file (so an older / previously generated one).

[kittaakos]

I'm collecting 'stacktraces' from ESP's in production. For every version in production that we release we collect / keep the ELF file. What I would like to be able (as we are able with the ESP8266) is to decode a stacktrace with a 'custom' ELF file (so an older / previously generated one).

Thank you, @dirkvranckaert

Do you know the path to the gdb, or do you expect the CLI to determine it based on the platform? If it's the latter, the Arduino CLI needs to be included as a tool to retrieve the build properties from the FQBN and calculate the gdb path, similar to how it is done in the decoder extension.

[dirkvranckaert]

I could determine the path to the GDB, on the other hand if the cli could determine it based on the platform that would be nice ;-) But for me it would be good enough if I can just run it (either from CLI either from Arduino IDE) by providing the ELF, the path to the GDB and the textual (by pasting or from a file) stacktrace

[zekageri]

This is the use case for us too.

[dirkvranckaert]

This is the use case for us too.

Also on esp32?

[zekageri]

Only on esp32 right now

[dirkvranckaert]

@zekageri How do you report crashes to your server / backend. We are currently struggling a bit for ESP32 in heaving them reported reliably...

[zekageri]

Esp32 is reading the core dump partition on boot and writing it to flash as a file. This file can be sent to server or be downloaded from the esp.

[dankeboy36]

Closing in favor of https://github.com/dankeboy36/trbr.

Please give it a try, you can decide how it should work. I will tweak further, but the preview binaries are available for download. I have done the manual testing only on macOS so far. Please let me know if you have any issues.

[zekageri]

Will try it on windows next week

[zekageri]

It does not start up. Just a flashing CMD window and it's gone. I have tried to disable my firewall and I have tried as administrator.

[dankeboy36]

It does not start up. Just a flashing CMD window and it's gone. I have tried to disable my firewall and I have tried as administrator.

Please open a new issue in the corresponding repo next time. Thank you for your help!

Moved to https://github.com/dankeboy36/trbr/issues/16.