[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 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.

[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

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|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 confusing 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
            Summary|eCos GDB stub "detach"      |eCos GDB stub "detach"
                   |reply incompatible with GDB |reply confusing with GDB
                   |7.4.1                       |7.4.1

--- Comment #5 from John Dallaway <john@dallaway.org.uk> 2012-06-30 17:44:30 BST ---
(In reply to comment #4)

> 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, I don't believe there is any misunderstanding here.

Someone, way back, decided that the eCos GDB stub should do _something_ with
detach requests rather than nothing at all. The processing of 'D' packets was
explicitly added to the stub 2001-08-24. It does seem strange to me that we
currently issue an empty reply (indicating that the command is not supported)
but then we go ahead and do something anyway (albeit with modified semantics).

I agree that it would be preferable to implement correct detach semantics. I
also agree that this not necessarily high priority. In the meantime, replying
"OK" ("I'm going to do something") still seems more correct to me than replying
with an empty string ("I'm ignoring this").

-- 
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 confusing 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 #6 from Jonathan Larmour <jifl@ecoscentric.com> 2012-07-01 00:08:55 BST ---
Created an attachment (id=1810)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1810)
Patch to remove 'detach' support

(In reply to comment #5)
> 
> Someone, way back, decided that the eCos GDB stub should do _something_ with
> detach requests rather than nothing at all.

As I mentioned before, my assumption for the rationale has been that it was
thought better to return to a ROM monitor (which, given Mark made this change,
would have been in the context of CygMon!) than just remain stuck in the stub.
As I said before this rationale is arguable. That doesn't make it right.

> The processing of 'D' packets was
> explicitly added to the stub 2001-08-24. It does seem strange to me that we
> currently issue an empty reply (indicating that the command is not supported)
> but then we go ahead and do something anyway (albeit with modified semantics).
> 
> I agree that it would be preferable to implement correct detach semantics. I
> also agree that this not necessarily high priority. In the meantime, replying
> "OK" ("I'm going to do something") still seems more correct to me than replying
> with an empty string ("I'm ignoring this").

But OK doesn't mean "I'm going to do something", it means "I'm going to
detach". But it doesn't do that.

So again, can you clarify what purpose you have for wanting to use detach,
since given the patch, you would want it to be doing something which is more
accurately served by 'kill'.

There are other GDB features that can't be properly supported by eCos, such as
inferior function calling - we don't promise to support everything GDB provides
just because GDB provides it.

So personally, I would be equally happy to remove 'D' packet support as
implement detach support. All that's needed is the attached patch. If no-one
needs detach semantics, then we should remove it as it doesn't match the
documented behaviour. Then GDB will return "Remote doesn't know how to detach"
and everything will be consistent with documented behaviour.

But it depends on why you wanted to use detach in the first place.

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.