This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
why does GDB always stop a thread when connecting?
- From: "taylor, david" <david dot taylor at emc dot com>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Mon, 28 Mar 2016 21:12:06 +0000
- Subject: why does GDB always stop a thread when connecting?
- Authentication-results: sourceware.org; auth=none
Why does GDB always stop a thread?
We set non-stop before connecting to our remote target.
And during the initial back and forth, GDB always tells the
first thread returned by qfThreadInfo to stop.
Because of this we have arranged for the first thread in the
list to be a thread that does nothing of consequence -- it is
imminently stoppable.
But, I would like to understand *WHY* GDB is stopping the thread.
While registers aren't available if the thread is not stopped, that is
to be expected. Memory can be read and written. Tracepoints and
breakpoints can be created, enabled, disabled, deleted... Trace
experiments can be run. Trace frames can be examined...
Why does GDB need a stopped thread when it connects to the
target?