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?