From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 854 invoked by alias); 23 Feb 2004 19:55:50 -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 846 invoked from network); 23 Feb 2004 19:55:49 -0000 Received: from unknown (HELO tisch.mail.mindspring.net) (207.69.200.157) by sources.redhat.com with SMTP; 23 Feb 2004 19:55:49 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AvMBA-0001em-00; Mon, 23 Feb 2004 14:55:48 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id B7CDD4B104; Mon, 23 Feb 2004 14:55:48 -0500 (EST) To: gdb@sources.redhat.com, jjohnstn@redhat.com Subject: regression with huge integer Message-Id: <20040223195548.B7CDD4B104@berman.michael-chastain.com> Date: Mon, 23 Feb 2004 19:55:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-02/txt/msg00328.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 (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. 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? Michael C