From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18664 invoked by alias); 23 Feb 2004 21:31:35 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18653 invoked from network); 23 Feb 2004 21:31:32 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 23 Feb 2004 21:31:32 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A51AE2B92; Mon, 23 Feb 2004 16:31:30 -0500 (EST) Message-ID: <403A7132.9020902@gnu.org> Date: Mon, 23 Feb 2004 21:31:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Michael Elizabeth Chastain , jjohnstn@redhat.com Cc: gdb@sources.redhat.com Subject: Re: regression with huge integer References: <20040223195548.B7CDD4B104@berman.michael-chastain.com> In-Reply-To: <20040223195548.B7CDD4B104@berman.michael-chastain.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00331.txt.bz2 > 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