[le700]

Closes #24

Detected ESP-IDF projects with a local ELF now decode program counters from Backtrace lines using the addr2line executable named by monitor_toolprefix.

The decoder leaves serial bytes unchanged, writes decoded frames to stderr, honors ESP_MONITOR_DECODE=0, and disables itself after a tool error so simulation continues without repeated failed spawns.

Validation:

• pnpm run build
• pnpm run test:vitest (lint and 93 tests)
• pnpm run format:check
• Decoder tests: 5 passed

Browser end-to-end and token-backed integration suites were not run locally.

Additional validation (2026-10-01)

Verified exact PR source 7de66fb16be02e09fa65e1f9196609b0632bb82d using the upstream Node.js 20 / pnpm lockfile environment: full workspace build, formatting and lint, CLI packaging for the five configured Linux/macOS/Windows targets, workspace package packing, all 93 Vitest tests, and all three Chromium/Firefox/WebKit embed tests passed.

Independent verification run: https://github.com/le700/launch/actions/runs/36752852577 (workflow checks out this PR's exact source; verification configuration is not part of this PR). Packaging does not establish execution on every target platform. The macOS packaging tool reported its signing warning. Token-dependent CLI/chip integration tests were not run; this is not a claim that the full upstream CI has passed.

Real external-tool verification (2026-10-01)

The exact PR source also passed a real GNU addr2line subprocess check using a freshly compiled ELF32/RISC-V program with debug symbols. The test independently locates the firmware_probe PC with nm, verifies addr2line's function/source line output, then sends a split Backtrace line through EspIdfBacktraceDecoder using its default execFile runner (no commandRunner mock) and verifies the decoded function and source line.

Run: https://github.com/le700/launch/actions/runs/36755635496 . This covers real ELF/tool invocation, not an ESP-IDF project or Wokwi service/device integration.

[le700]

I checked the newly run upstream Tests workflow on 7de66fb16be02e09fa65e1f9196609b0632bb82d.

The test job completed the build, package/pack checks, format/lint, all 93 Vitest tests, and all three Playwright embed tests. It then stopped at CLI integration because WOKWI_CLI_TOKEN was unset. The test_chip_integration job compiled the custom chip and stopped when its simulation reported the same missing token. Both failures occur in token-backed integration steps; the logs do not show a failure in the new decoder.

The PR's independent runs cover packaging/browser tests and a real ELF32/RISC-V + GNU addr2line decoder invocation, but they do not replace the token-backed integration suites. Could a maintainer run those suites in an approved environment with the token, or advise the preferred way to validate them for fork PRs? I have left the tests and CI workflow unchanged.

[le700]

I resolved the merge conflict by merging the current main (7cf4ffa) and kept both the ESP-IDF backtrace documentation and the newer SD-card documentation. Updated head: 2357978b4f98cb3bd95dbcd4d0cb46587c414e1b.

Verified on this merged tree: pnpm -r run build; pnpm test:vitest (lint + 116 tests); pnpm --filter @wokwi/cli test (lint + 41 tests); and pnpm format:check. The token-backed CLI/chip integration steps still need the upstream WOKWI_CLI_TOKEN environment described above.