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

Godmar Back godmar@gmail.com
Wed Feb 7 03:38:00 GMT 2007


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
 >



More information about the Gdb-prs mailing list