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: "Godmar Back" <godmar at gmail dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 7 Feb 2007 03:38:01 -0000
- Subject: Re: backtrace/2224: backtrace doesn't work with bochs stub anymore
- Reply-to: "Godmar Back" <godmar at gmail dot com>
The following reply was made to PR backtrace/2224; it has been noted by GNATS.
From: "Godmar Back" <godmar@gmail.com>
To: "Daniel Jacobowitz" <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: backtrace/2224: backtrace doesn't work with bochs stub anymore
Date: Tue, 6 Feb 2007 22:29:09 -0500
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.
However, this is not the issue. gdb has been complaining about that in
the version that shows backtraces as well.
[ aside: the gdb remote stub spec doesn't say what error codes should
be used, perhaps this is why the author of bochs literally sends back
a "NN" instead ]
My comparative analysis is that qemu's stub:
- ignores qOffsets with a +$# response
- ignores qPart:auxv.... equally
but gets gdb to send it the necessary m commands to extract the backtrace.
bochs's stub, on the other hand,
- answers qOffsets
- sends an error back for qPart:auxv (which, admittedly is malformed!)
But gdb never sends bochs the command for the backtrace. Instead, it sends this
$P8=0cbc10c0#
(is OK'd)
$P29=FFFFFFFF#
(is OK'd)
Then gdb sends again the qPart which causes the error.
This is shown in the last 20 lines or so here:
http://people.cs.vt.edu/~gback/pintos/bochs-gdb.txt
I think that despite the fact that "ENN" is obviously a malformed
response to $qPart...., gdb should gracefully ignore it, and in the
gdb that ships with FC4 it did. (We used it last semester here for our
OS course, which uses bochs 2.2.6 + gdb.)
My .2c
- Godmar
On 2/6/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, Feb 06, 2007 at 10:14:04PM -0500, Godmar Back wrote:
> > Output when it doesn't work - with bochs's stub:
> > (gdb) target remote pistachio:1235
> > Remote debugging using pistachio:1235
> > 0x0000fff0 in ?? ()
> > Reply contains invalid hex digit 78
>
> Something seems wrong with your stub. Could you repeat with set
> debug remote 1 before connecting?
>
> --
> Daniel Jacobowitz
> CodeSourcery
>