why does GDB always stop a thread when connecting?

why does GDB always stop a thread when connecting?

[taylor, david]

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?

Re: why does GDB always stop a thread when connecting?

[Luis Machado]

On 03/28/2016 04:12 PM, taylor, david wrote:
> 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?
>
>

Does setting "may-interrupt" to "off" help?

Re: why does GDB always stop a thread when connecting?

[David Taylor]

    On 04/05/2016 01:43 PM, Luis Machado wrote:

    Does setting "may-interrupt" to "off" help?

I'll try that as a possible kludgey workaround.  But, if it works, since
the user should be able to stop and interrupt threads -- we just don't
want GDB doing so when not asked to do so -- it would mean the user
or the GUI would have to do something like:

    set may-interrupt off
    issue target command...
    set may-interrupt on

For our target, and I suspect for many of the non-stop remote targets
out there, the only GDB operations that come to mind that require a
stopped thread are to read and/or write the registers of the thread and
to single step the thread.

We do not require a stopped thread to create or delete breakpoints.  To
enable of disable breakpoints.  To create, delete, enable, or disable
tracepoints.  To start or stop a trace experiment.  To read or write
memory.

IF there is no good reason for the current behavior, then I'm willing to
write and test a patch.  If there is a good reason, then perhaps a new
user settable variable is needed to decide whether to do the pointless
and gratuitous (to me) stop of a thread when connecting.

David