Remote Serial Protocol -- reply to '?' when target running

Remote Serial Protocol -- reply to '?' when target running

[Michael Eager]

When gdb connects to a remote target, it asks about
features, and then sends a '?' packet, asking why the
target is stopped.  When the target connection is through
a JTAG pod, the pod may be able to respond to the feature
request, but not be able to determine what the current state of
the target is, likely because it is not stopped.  What should a
JTAG pod reply in this case?

The GDB Remote Protocol doc doesn't seem to be entirely consistent.

The description for '?' is
   Indicate the reason the target halted. The reply is the
   same as for step and continue.

The description for Stop Reply Packet says the following:
   The ‘C’, ‘c’, ‘S’, ‘s’, ‘vCont’, ‘vAttach’, ‘vRun’, ‘vStopped’,
   and ‘?’ packets can receive any of the below as a reply. Except
   for ‘?’ and ‘vStopped’, that reply is only returned when the
   target halts.

This suggests that the target can reply to '?' even if it is not
stopped, which seems to contradict the description for '?'.  But
none of the listed replies seem to be appropriate.  None of the
replies look like "Don't bother me, I'm busy".

How should the JTAG pod respond?  What do most do in this situation?

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

RE: Remote Serial Protocol -- reply to '?' when target running

[taylor, david]

> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Michael Eager


> When gdb connects to a remote target, it asks about
> features, and then sends a '?' packet, asking why the
> target is stopped.  When the target connection is through
> a JTAG pod, the pod may be able to respond to the feature
> request, but not be able to determine what the current state of
> the target is, likely because it is not stopped.  What should a
> JTAG pod reply in this case?
> 
> The GDB Remote Protocol doc doesn't seem to be entirely consistent.

Sounds like you are in non-stop mode...  our stub 

In 'Remote Protocol Support for Non-Stop Mode' (part of appendix E), it says in part:

    If all threads are running when the target receives the '?' packet,
    or if the target is not attached to any process, it shall respond 'OK'.

I don’t know about others, but we operate in non-stop mode and if there
 are no stopped threads, we respond with 'OK'.

Re: Remote Serial Protocol -- reply to '?' when target running

[Gareth McMullin]

On Wed, Aug 10, 2016 at 5:33 AM, Michael Eager <eager@eagerm.com> wrote:
>
> When gdb connects to a remote target, it asks about
> features, and then sends a '?' packet, asking why the
> target is stopped.  When the target connection is through
> a JTAG pod, the pod may be able to respond to the feature
> request, but not be able to determine what the current state of
> the target is, likely because it is not stopped.  What should a
> JTAG pod reply in this case?
>
> The GDB Remote Protocol doc doesn't seem to be entirely consistent.
>
> The description for '?' is
>   Indicate the reason the target halted. The reply is the
>   same as for step and continue.
>
> The description for Stop Reply Packet says the following:
>   The ‘C’, ‘c’, ‘S’, ‘s’, ‘vCont’, ‘vAttach’, ‘vRun’, ‘vStopped’,
>   and ‘?’ packets can receive any of the below as a reply. Except
>   for ‘?’ and ‘vStopped’, that reply is only returned when the
>   target halts.
>
> This suggests that the target can reply to '?' even if it is not
> stopped, which seems to contradict the description for '?'.  But
> none of the listed replies seem to be appropriate.  None of the
> replies look like "Don't bother me, I'm busy".
>
> How should the JTAG pod respond?  What do most do in this situation?

I can't comment on others, but the Black Magic debug project that I maintain [1]
implements the extended-remote prototcol, and initially responds to
'?' with 'W00' indicating
the target exited (there is no attached target).  The user initiates a
scan for connected
targets with 'monitor jtag_scan' from GDB, and then uses the GDB
'attach' command
to connect, sending the 'vAttach' packet.  This interrupts the target
and the reply comes
back as 'T05'.

[1] https://github.com/blacksphere/blackmagic

RE: Remote Serial Protocol -- reply to '?' when target running

[taylor, david]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1299 bytes --]


> From: Michael Eager [mailto:eager@eagerm.com]
> Sent: Tuesday, August 09, 2016 3:08 PM
> To: taylor, david; gdb@sourceware.org
> Subject: Re: Remote Serial Protocol -- reply to '?' when target running
> 
> On 08/09/2016 11:40 AM, taylor, david wrote:
> >> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org]
> On
> >> Behalf Of Michael Eager

> The JTAG pod I'm using does not respond with "QNonStop+" in response
> to "qSupported".  Perhaps it should.

Our stub sets it and I also do 'set non-stop on' in my .gdbinit file.  The entry in
my .gdbinit might predate the stub returning it, I don't recall.

> The JTAG pod does respond to '?' with OK.  After a few other exchanges,
> gdb goes into a wait, waiting to receive something from the target.
> 
> What do you do?  Send a stop reply packet when the target stops?

Our target typically has 80-110 threads when I connect.
We support asynchronous notifications as well.

When GDB connects to the target, a thread is created to service GDB.
If multiple GDB's connect, multiple threads get created -- each dedicated
to a specific GDB.

There's also a networking thread and a bunch of other threads.

Our target never stops.  Individual threads?  Yes.  The target as a whole?  No.
\x16º&ÖëzÛ«ŸŽvשb²Ö«r\x18\x1d

Re: Remote Serial Protocol -- reply to '?' when target running

[Michael Eager]

On 08/09/2016 12:27 PM, taylor, david wrote:
>
>> From: Michael Eager [mailto:eager@eagerm.com]
>> Sent: Tuesday, August 09, 2016 3:08 PM
>> To: taylor, david; gdb@sourceware.org
>> Subject: Re: Remote Serial Protocol -- reply to '?' when target running
>>
>> On 08/09/2016 11:40 AM, taylor, david wrote:
>>>> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org]
>> On
>>>> Behalf Of Michael Eager
>
>> The JTAG pod I'm using does not respond with "QNonStop+" in response
>> to "qSupported".  Perhaps it should.
>
> Our stub sets it and I also do 'set non-stop on' in my .gdbinit file.  The entry in
> my .gdbinit might predate the stub returning it, I don't recall.
>
>> The JTAG pod does respond to '?' with OK.  After a few other exchanges,
>> gdb goes into a wait, waiting to receive something from the target.
>>
>> What do you do?  Send a stop reply packet when the target stops?
>
> Our target typically has 80-110 threads when I connect.
> We support asynchronous notifications as well.
>
> When GDB connects to the target, a thread is created to service GDB.
> If multiple GDB's connect, multiple threads get created -- each dedicated
> to a specific GDB.
>
> There's also a networking thread and a bunch of other threads.
>
> Our target never stops.  Individual threads?  Yes.  The target as a whole?  No.

Thanks.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077