This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: regression with huge integer
- From: Andrew Cagney <cagney at gnu dot org>
- To: Michael Elizabeth Chastain <mec dot gnu at mindspring dot com>,jjohnstn at redhat dot com
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 23 Feb 2004 16:31:30 -0500
- Subject: Re: regression with huge integer
- References: <20040223195548.B7CDD4B104@berman.michael-chastain.com>
gdb.stabs/weird.def has this huge integer:
# 256-bit integer. The point is obviously not that GDB should have a
# special case for this size, but that an integer of any size should
# work (at least for printing in hex, not necessarily for arithmetic.
.stabs "int256var:G203=bu32;0;256;", N_GSYM,0,0, 0
# The value is palindromic, so it works whether words are big or little
# endian.
.globl int256var
.data
.align_it
int256var:
.long 42
.long 0x2b, 0x2c, 0x2d, 0x2d, 0x2c, 0x2b, 0x2a
gdb 6.0 can print this just fine:
(gdb) print int256var
$1 = 0x0000002a0000002b0000002c0000002d0000002d0000002c0000002b0000002a
That should be decimal :-/
(gdb) print /x int256var
$2 = 0x0000002a0000002b0000002c0000002d0000002d0000002c0000002b0000002a
But with the recent simplification to print_scalar_formatted, gdb HEAD says:
(gdb) print int256var
$1 = 0x0000002a0000002b0000002c0000002d0000002d0000002c0000002b0000002a
(gdb) print /x int256var
$2 = That operation is not available on integers of more than 8 bytes.
This causes a regression in the test results.
Hmm, two steps forward, one step back.
I would like to just accept this output and change the test script.
Specifically, in gdb.stabs/weird.exp:
# This big number needs to be kept as one piece
- gdb_test "p/x int256var" " = 0x0*2a0000002b0000002c0000002d0000002d0000002c0000002b0000002a" "print very big integer"
+ gdb_test "print int256var" " = 0x0*2a0000002b0000002c0000002d0000002d0000002c0000002b0000002a" "print very big integer"
Is this a good idea? Or should I file a bug that "print /x" does not work
in this case?
Jeff and I looked at the problem.
Given some sort of very large scalar _and_ a scalar format, I think GDB
can correctly print it. Looking at the old 60 code, this:
if (len > sizeof (LONGEST)
&& (format == 't'
|| format == 'c'
|| format == 'o'
|| format == 'u'
|| format == 'd'
|| format == 'x'))
{
if (!TYPE_UNSIGNED (type)
|| !extract_long_unsigned_integer (valaddr, len, &val_long))
{
/* We can't print it normally, but we can print it in hex.
Printing it in the wrong radix is more useful than saying
"use /x, you dummy". */
/* FIXME: we could also do octal or binary if that was the
desired format. */
/* FIXME: we should be using the size field to give us a
minimum field width to print. */
if (format == 'o')
print_octal_chars (stream, valaddr, len);
else if (format == 'd')
print_decimal_chars (stream, valaddr, len);
else if (format == 't')
print_binary_chars (stream, valaddr, len);
else
/* replace with call to print_hex_chars? Looks
like val_print_type_code_int is redoing
work. - edie */
val_print_type_code_int (type, valaddr, stream);
would just need to be seriously reduced to something like:
if (len > sizeof (LONGEST)
&& some sort of scalar (TYPE)
&& some sort of scalar (FORMAT))
if (format == ..)
print_FORMAT_chars (...);
...
else if (format == 'x')
print_hex_chars (...);
else
we've botched it -- don't call val_print_type_code_int
where each format is explicitly handled. ...
The only one that appears to be missing is 'c', and there something very
similar to print_hex_chars would do the trick (using LA_EMIT_CHAR).
It might even, eventually, be possible to simplify this code to the
point where all scalar formatted scalars are always printed directly
from their byte buffer (no unpack longest call).
Andrew