Re: backtrace/2224: backtrace doesn't work with bochs stub anymore

[Daniel Jacobowitz <drow at false dot org>]

The following reply was made to PR backtrace/2224; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: Godmar Back <godmar@gmail.com>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: backtrace/2224: backtrace doesn't work with bochs stub anymore
Date: Wed, 7 Feb 2007 11:27:22 -0500

 On Tue, Feb 06, 2007 at 11:12:01PM -0500, Godmar Back wrote:
 > On 2/6/07, Godmar Back <godmar@gmail.com> wrote:
 > >On 2/6/07, Daniel Jacobowitz <drow@false.org> wrote:
 > >> On Tue, Feb 06, 2007 at 10:29:09PM -0500, Godmar Back wrote:
 > >> > You mean the "invalid hex digit 78" message?
 > >> > I'm pretty sure this is because the bochs stub, which is the stub that
 > >> > has the issue, sends the string literal "ENN" instead of "Enn" where
 > >> > "nn" is a hex number.  Note that 'N' is dec 78.
 > >>
 > >> Note, this is not a command error (part of the protocol) it's a
 > >> protocol error.  GDB may just throw up its hands and stop talking to
 > >> the target.
 > >>
 > 
 > Indeed, changing bochs such that it returns "Eff" instead of "ENN"
 > fixed the issue.
 > I will file a bug report with bochs.
 > 
 > I would urge you to consider, however, to recreate the earlier, more
 > permissive protocol handling you had in place for earlier gdb
 > versions.
 
 There has been no change.  Earlier versions didn't send this particular
 packet, which was only added recently, so did not trigger the bochs bug
 of an incorrect reply.
 
 You are responding to a packet that you don't recognize.  Therefore the
 right response is $#00, the empty packet, which informs GDB that you
 don't recognize it.  This is described in the manual.
 
 If you tell GDB "something has gone wrong but we don't know what, so
 here, have something syntactically incorrect" it is better for it to
 stop and inform the user that something has gone wrong.  It could be
 out of sync with the stub, which can lead to many hard to debug
 problems - especially in new GDB versions.
 
 By the way, for an Enn response it doesn't currently matter what
 error code you use - GDB doesn't interpret any of them specially.
 That's a long standing weakness of the protocol; error behavior
 is underspecified.
 
 > See also Postel's Law: http://en.wikipedia.org/wiki/Postel's_law
 
 The response at the bottom seems very apt.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery