This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: backtrace/2224: backtrace doesn't work with bochs stub anymore
- From: Daniel Jacobowitz <drow at false dot org>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 7 Feb 2007 16:28:01 -0000
- Subject: Re: backtrace/2224: backtrace doesn't work with bochs stub anymore
- Reply-to: 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