aboutsummaryrefslogtreecommitdiff
path: root/gdb/ppc-ravenscar-thread.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2013-04-19 14:13:30 +0000
committerPedro Alves <palves@redhat.com>2013-04-19 14:13:30 +0000
commit433730c97306608f78fc8de0a319c9a5c6758db2 (patch)
tree3c091949746367cefae0e6dde17a45d643c9d65d /gdb/ppc-ravenscar-thread.c
parentcb948fc00e2e37d0eb00fe0a822fbc38394759f4 (diff)
downloadgdb-433730c97306608f78fc8de0a319c9a5c6758db2.zip
gdb-433730c97306608f78fc8de0a319c9a5c6758db2.tar.gz
gdb-433730c97306608f78fc8de0a319c9a5c6758db2.tar.bz2
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.
Diffstat (limited to 'gdb/ppc-ravenscar-thread.c')
0 files changed, 0 insertions, 0 deletions