[A13xB0]

For #191. This covers the three steps in the plan, except catching a native node at boot.

Native nodes

• node.debug {node} returns the PID, the binary, whether it has symbols (debug, symbols or stripped), a gdb -p command line and a VS Code attach configuration.
• From then on the node is held, not marked down, when a breakpoint stops it answering ticks. The rest of the mesh carries on, and when the debugger lets it go, it catches up to the run's clock and rejoins. This is in engine/debug.go. sim.state reports the run as not reproducible after this, because the node's clock jumps.

Emulated boards

• node.debug {node, wait?, port?} restarts the board with the emulator's GDB stub: QEMU -gdb tcp:127.0.0.1:PORT (plus -S with wait), Renode machine StartGdbServer. It returns the gdb for the board's architecture and a VS Code launch configuration.
• off undoes either case.

UI and docs

• "Debug this node" on the node row menu. The status line shows the attach command.
• New page: docs/debugging-firmware.md.

Tested

• Unit tests for the hold/rejoin cycle and for the stub arguments.
• Live: a native node SIGSTOPped as a breakpoint would stop it is held while the run advances 5 s, then rejoins without being marked down.
• RAK_4631 under Renode: gdb connects and reads the PC. With wait the PC is 0xa80 (held at reset), and it runs on after gdb detaches.
• Heltec_v3 under QEMU: the stub answers RSP ? with T05.

I used this to find #565: a breakpoint after the SoftDevice's svc 0x28 showed NRF_ERROR_FORBIDDEN.

Not done: holding a native node before setup(). It runs as soon as the process connects, so that needs a flag in meshcore-native.