]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/testsuite/ChangeLog
Fix the x87 FP register printout when issuing the “info float” command.
authorPedro Alves <palves@redhat.com>
Fri, 19 Apr 2013 14:13:30 +0000 (14:13 +0000)
committerPedro Alves <palves@redhat.com>
Fri, 19 Apr 2013 14:13:30 +0000 (14:13 +0000)
commit433730c97306608f78fc8de0a319c9a5c6758db2
tree3c091949746367cefae0e6dde17a45d643c9d65d
parentcb948fc00e2e37d0eb00fe0a822fbc38394759f4
Fix the x87 FP register printout when issuing the “info float” command.

Consider the following simple program:

.globl  _start
.text
_start:
      fldt    val
.data
      val: .byte 0x00,0x00,0x45,0x07,0x11,0x19,0x22,0xe9,0xfe,0xbf

With current GDB on x86-64 GNU/Linux hosts, after the moment the fldt
command has been executed the register st(0) looks like this,
according to the “info regs” output (TOP=7):

  R7: Valid   0xffffffbffffffffeffffffe922191107450000 -0.910676542908976927

which is clearly wrong (just count its length).  The problem is due to
the printf statement (see patch) printing a promoted integer value of
a char argument "raw[i]", and, since char is signed on x86-64
GNU/Linux, the erroneous “ffffff” are printed for the first three
bytes which turn out to be "negative".  The fix is to use gdb_byte
instead which is unsigned (and is the type of value_contents(), the
type to be used for raw target bytes anyway).  After the fix the value
will be printed correctly:

  R7: Valid   0xbffee922191107450000 -0.910676542908976927

gdb/
2013-04-19  Vladimir Kargov <kargov@gmail.com>
    Pedro Alves  <palves@redhat.com>

* i387-tdep.c (i387_print_float_info): Use gdb_byte for pointer to
value contents.

gdb/testsuite/
2013-04-19  Vladimir Kargov  <kargov@gmail.com>
    Pedro Alves  <palves@redhat.com>

* gdb.arch/i386-float.S: New file.
* gdb.arch/i386-float.exp: New file.
gdb/ChangeLog
gdb/i387-tdep.c
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.arch/i386-float.S [new file with mode: 0644]
gdb/testsuite/gdb.arch/i386-float.exp [new file with mode: 0644]