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 03:48: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: Tue, 6 Feb 2007 22:38:33 -0500
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.
If you could repeat the test in both qemu and bochs, and in both cases
use "set debug target 1" and "set debug frame 1" before connecting, and
run from the target command to the failing backtrace, then I'll be able
to see what's _really_ going on in your sessions. I think it's
probably something totally different, e.g. in memory.
--
Daniel Jacobowitz
CodeSourcery