From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14123 invoked by alias); 23 Feb 2004 22:25:53 -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 14116 invoked from network); 23 Feb 2004 22:25:51 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 23 Feb 2004 22:25:51 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 4DD5280001E; Mon, 23 Feb 2004 17:25:50 -0500 (EST) Message-ID: <403A7DEE.6090606@redhat.com> Date: Mon, 23 Feb 2004 22:25:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: Andrew Cagney Cc: Michael Elizabeth Chastain , gdb@sources.redhat.com Subject: Re: regression with huge integer References: <20040223195548.B7CDD4B104@berman.michael-chastain.com> <403A7132.9020902@gnu.org> In-Reply-To: <403A7132.9020902@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00334.txt.bz2 Andrew Cagney wrote: >> 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 > > > I'll start working on a patch and submit it for review. -- Jeff J.