[Bug 1001614] New: eCos GDB stub "detach" reply incompatible with GDB 7.4.1

[Bug 1001614] New: eCos GDB stub "detach" reply incompatible with GDB 7.4.1

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001614

           Summary: eCos GDB stub "detach" reply incompatible with GDB
                    7.4.1
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: normal
         Component: GDB stubs
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: john@dallaway.org.uk
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


The generic eCos GDB stub code replies to a "D" detach packet with an empty
string. This causes GDB 7.4.1 to report "Remote doesn't know to detach".
According to GDB documentation, the GDB stub should reply "OK" to indicate
success - otherwise GDB will believe it is still attached to the target:

(gdb) det
Sending packet: $qTStatus#49...Ack
Packet received: 
Sending packet: $D#44...Ack
Packet received: 
Remote doesn't know how to detach
(gdb) 

Older GDB will interpret a reply of either "OK" or an empty string as an
indication of success (tested with GDB 5.3).

Patch to follow.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001614] eCos GDB stub "detach" reply incompatible with GDB 7.4.1

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001614

--- Comment #1 from John Dallaway <john@dallaway.org.uk> 2012-06-24 17:48:43 BST ---
Created an attachment (id=1803)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1803)
gdb-stub-detach-120624.patch

The patch resolves the reported issue by replying "OK" (rather than an empty
string) to GDB detach requests ("D" packets).

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001614] eCos GDB stub "detach" reply incompatible with GDB 7.4.1

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001614

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |jifl@ecoscentric.com
         AssignedTo|unassigned@bugs.ecos.source |jifl@ecoscentric.com
                   |ware.org                    |

--- Comment #2 from Jonathan Larmour <jifl@ecoscentric.com> 2012-06-25 13:28:42 BST ---
The patch isn't right. GDB is correct - the remote side doesn't know how to
detach, hence the "null" packet rather than OK.

In all versions of GDB to date, GDB will stop talking to the target (closing
tcp socket if needed) anyway. I assume that is still the case in 7.4.1? e.g. if
you try and quit gdb, it won't complain it is still attached to the target. For
that reason at present we treat detach the same as 'kill', which this patch
wouldn't change. We treat it as 'kill' because it's arguably better to
potentially return to redboot (if applicable) than just get stuck forever in
the stub until a manual reset.

We could make a few changes to support detach properly with I think a bit of
extra code and a little global data, but is this an important enough feature to
add if no-one actually uses it the way it's intended? Presumably you don't
actually need the correct behaviour since this patch would continue to make it
identical to 'kill', as all this patch does is silence the message.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001614] eCos GDB stub "detach" reply incompatible with GDB 7.4.1

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001614

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|MODIFIED                    |NEEDINFO

--- Comment #4 from Jonathan Larmour <jifl@ecoscentric.com> 2012-06-25 15:46:23 BST ---
(In reply to comment #3)
> (In reply to comment #2)
> 
> > The patch isn't right. GDB is correct - the remote side doesn't know how to
> > detach, hence the "null" packet rather than OK.
> > 
> > In all versions of GDB to date, GDB will stop talking to the target (closing
> > tcp socket if needed) anyway. I assume that is still the case in 7.4.1?
> 
> It is not still the case.

That's annoying. It was the case in 7.3.1.

> > Presumably you don't
> > actually need the correct behaviour since this patch would continue to make it
> > identical to 'kill', as all this patch does is silence the message.
> 
> The rationale for the patch is just to allow us to work with eCos stubs and GDB
> 4.7.1 without the confusing messages and prompts shown above. Can you suggest a
> better approach?

Yes, although looking closer I see I would need to contribute a couple of
eCosCentric patches first to get the most coherent and sensible fix. That can
be done, however, I'm still not clear as to why you even want to use detach
given that the behaviour you are getting at present (pre 7.4, or post 7.4 with
your patch) is not that of detach, but the same as kill. Why not just use kill?

> I note that some JTAG debuggers allow the interpretation of the GDB detach
> command to be configured (resume execution, reset, halt, nothing) but they
> always reply "OK".

By "some" I assume you mean OpenOCD. The semantics of 'detach' are well
defined. OpenOCD does at least default to the correct behaviour, so at least
anything else is known hacky behaviour which the user is aware of. Although
none of those options for OpenOCD correspond to our current behaviour of 'kill'
either.

FAOD the reason we haven't replied OK before is because we have not, to date,
implemented detach. I would feel happier taking the time to add this support,
and increasing stub size a tiny amount, if I knew it was for a valuable and
useful reason rather than potentially just a misunderstanding of the purpose of
detach versus kill.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001614] eCos GDB stub "detach" reply incompatible with GDB 7.4.1

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001614

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |MODIFIED

--- Comment #3 from John Dallaway <john@dallaway.org.uk> 2012-06-25 14:40:43 BST ---
(In reply to comment #2)

> The patch isn't right. GDB is correct - the remote side doesn't know how to
> detach, hence the "null" packet rather than OK.
> 
> In all versions of GDB to date, GDB will stop talking to the target (closing
> tcp socket if needed) anyway. I assume that is still the case in 7.4.1?

It is not still the case. GDB 7.4.1 is apparently left in the same state as if
the detach command had not been issued:

(gdb) tar rem /dev/ttyS0
Remote debugging using /dev/ttyS0
0x01003688 in ?? ()
(gdb) det
Remote doesn't know how to detach
(gdb) tar rem /dev/ttyS0
A program is being debugged already.  Kill it? (y or n) y

Remote debugging using /dev/ttyS0
0x01003688 in ?? ()
(gdb) det
Remote doesn't know how to detach
(gdb) q
A debugging session is active.

        Inferior 1 [Remote target] will be killed.

Quit anyway? (y or n) y

> Presumably you don't
> actually need the correct behaviour since this patch would continue to make it
> identical to 'kill', as all this patch does is silence the message.

The rationale for the patch is just to allow us to work with eCos stubs and GDB
4.7.1 without the confusing messages and prompts shown above. Can you suggest a
better approach?

I note that some JTAG debuggers allow the interpretation of the GDB detach
command to be configured (resume execution, reset, halt, nothing) but they
always reply "OK".

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001614] eCos GDB stub "detach" reply incompatible with GDB 7.4.1

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001614

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |jifl@ecoscentric.com
         AssignedTo|unassigned@bugs.ecos.source |jifl@ecoscentric.com
                   |ware.org                    |

--- Comment #2 from Jonathan Larmour <jifl@ecoscentric.com> 2012-06-25 13:28:42 BST ---
The patch isn't right. GDB is correct - the remote side doesn't know how to
detach, hence the "null" packet rather than OK.

In all versions of GDB to date, GDB will stop talking to the target (closing
tcp socket if needed) anyway. I assume that is still the case in 7.4.1? e.g. if
you try and quit gdb, it won't complain it is still attached to the target. For
that reason at present we treat detach the same as 'kill', which this patch
wouldn't change. We treat it as 'kill' because it's arguably better to
potentially return to redboot (if applicable) than just get stuck forever in
the stub until a manual reset.

We could make a few changes to support detach properly with I think a bit of
extra code and a little global data, but is this an important enough feature to
add if no-one actually uses it the way it's intended? Presumably you don't
actually need the correct behaviour since this patch would continue to make it
identical to 'kill', as all this patch does is silence the message.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001614] eCos GDB stub "detach" reply incompatible with GDB 7.4.1

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001614

--- Comment #1 from John Dallaway <john@dallaway.org.uk> 2012-06-24 17:48:43 BST ---
Created an attachment (id=1803)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1803)
gdb-stub-detach-120624.patch

The patch resolves the reported issue by replying "OK" (rather than an empty
string) to GDB detach requests ("D" packets).

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.