This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Please do not reply to this email. Use the web interface provided at:

John Dallaway <> 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 <> 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:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]