idf.py spawns gdb process within a thread and uses Thread.join() to wait
for the gdb process to finish. As CTRL+C(SIGINT) is used by gdb to interrupt the
running program, we catch the SIGINT while waiting on the gdb to finish,
and try Thread.join() again.
With cpython's commit
commit a22be4943c119fecf5433d999227ff78fc2e5741
Author: Victor Stinner <vstinner@python.org>
Date: Mon Sep 27 14:20:31 2021 +0200
bpo-45274: Fix Thread._wait_for_tstate_lock() race condition (GH-28532)
this logic doesn't work anymore, because cpython internally marks the
thread as stopped when join() is interrupted with an exception. IMHO
this is broken in cpython and there is a bug report about this
https://github.com/python/cpython/issues/90882. Problem is that
waiting on a thread to finish is based on acquiring a lock. Meaning
join() is waiting on _tstate_lock. If this wait is interrupted, the
above referenced commit adds a logic that checks if the lock is help,
meaning the thread is done and marks the thread as stopped. But there is
no way to tell if the lock was acquired by us running join() or if it's
held by someone else e.g. still by the thread bootstrap code. Meaning
the thread is still running.
I may be missing something, but I don't see any reason why to spawn gdb
process within a thread. This change removes the thread and spawns gdb
directly. Instead waiting on a thread, we wait on the process to finish,
replacing join() with wait() and avoiding this problem.
Closes https://github.com/espressif/esp-idf/issues/11871
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The debug targets are currently not utilizing hints, because they
are not using RunTool() helper from tools.py to spawn sub-processes.
Adjusting debug targets to use RunTool() would require some significant
changes to debug targets and RunTool() as well. Since debug targets
are already storing their output in logs, we can use these and process
them for hints.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently loading of esp32s3 ROM ELF symbols fails with
"Cannot access memory at address 0x3ff194ad". Let's perform
add-symbol-file after connection to the target.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
When multiple targets are specified, e.g. idf.py flash monitor, the
automatic port detection is performed twice. Keep the port value in
args.port and avoid multiple calls to get_default_serial_port().
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Since both chips have built-in JTAG functionality, and there are no
official boards with FT2232H for these chips, use the built-in JTAG
by default.
To use them with esp-prog, set:
OPENOCD_COMMANDS="-f board/esp32c3-ftdi.cfg"
or pass this via the --openocd-commands argument to idf.py.
GDB with python support will automatically load freertos-gdb python module.
It comes to GDB with commands starting with 'freertos' to show human-readable
tables with freertos task/queue/timer information
Python module URL: https://pypi.org/project/freertos-gdb
When idf.py gdb starts, it expects openocd was started in the background
and creates a thread to watch for openocd errors. when gdb target exits,
the debug_ext.py aims to cleanup all threads and processes, but fails
with traceback if openocd-watch thread not available, which could happen
if openocd started separately.
Support for execution of asynchronous target, such as openocd, which
by default runs in the background, but if it's the only target idf.py
outputs the openocd in the console waiting for termination by user.
Supports also blocking commands gdb and gdbtui to start a debugging
session in an active console.
Supports running gdbgui running a UI debugging session in a browser
window, using the active console for other commands, such as openocd
or monitor.
Supports combining the debug targets in one action list, such as
idf.py openocd gdbgui monitor
