regression with huge integer

regression with huge integer

[Michael Elizabeth Chastain]

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

Re: regression with huge integer

[Andreas Schwab]

mec.gnu@mindspring.com (Michael Elizabeth Chastain) writes:

> 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.

That looks like gdb is contradicting itself.  It can print in hex, but
then asked to print in hex it cannot. :-)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: regression with huge integer

[Mark Kettenis]

   From: Andreas Schwab <schwab@suse.de>
   Date: Mon, 23 Feb 2004 21:42:25 +0100

   mec.gnu@mindspring.com (Michael Elizabeth Chastain) writes:

   > 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.

   That looks like gdb is contradicting itself.  It can print in hex, but
   then asked to print in hex it cannot. :-)

So this test uncovers a genuine bug.  Therefore, we shouldn't adjust
the testsuite.

Mark

Re: regression with huge integer

[Andrew Cagney]

> 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

Re: regression with huge integer

[Jeff Johnston]

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.

[RFA]: Patch for regression with huge integer

[Jeff Johnston]

[-- Attachment #1: Type: text/plain, Size: 3615 bytes --]

Jeff Johnston wrote:
> Andrew Cagney wrote:
> 
>>
>>>   (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.
>>
>>
>>
>>
>> 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.
> 
> 

Ok to commit?  I added a function to print out the char format.  It does not 
print out leading zero bytes.  Thus, if you set some large integer value to 'a', 
it would print out just 'a'.

I have verified this fixes the regression in gdb.stabs/weird.exp

2004-02-26  Jeff Johnston  <jjohnstn@redhat.com>

         * valprint.h (print_hex_chars, print_char_chars): New prototypes.
         * valprint.c (print_hex_chars): Change from static to external.
         (print_char_chars): New function.
         * printcmd.c (print_scalar_formatted): For integer and enum types
         that are longer than LONGEST, perform processing via appropriate
         print_*_chars routines.



[-- Attachment #2: printcmd.patch --]
[-- Type: text/plain, Size: 3328 bytes --]

Index: valprint.h
===================================================================
RCS file: /cvs/src/src/gdb/valprint.h,v
retrieving revision 1.4
diff -u -p -r1.4 valprint.h
--- valprint.h	6 Apr 2003 19:25:04 -0000	1.4
+++ valprint.h	26 Feb 2004 22:07:15 -0000
@@ -63,4 +63,10 @@ extern void print_octal_chars (struct ui
 
 extern void print_decimal_chars (struct ui_file *, unsigned char *,
 				 unsigned int);
+
+extern void print_hex_chars (struct ui_file *, unsigned char *,
+			     unsigned int);
+
+extern void print_char_chars (struct ui_file *, unsigned char *,
+			      unsigned int);
 #endif
Index: valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/valprint.c,v
retrieving revision 1.31
diff -u -p -r1.31 valprint.c
--- valprint.c	21 Sep 2003 01:26:45 -0000	1.31
+++ valprint.c	26 Feb 2004 22:07:15 -0000
@@ -42,9 +42,6 @@
 static int partial_memory_read (CORE_ADDR memaddr, char *myaddr,
 				int len, int *errnoptr);
 
-static void print_hex_chars (struct ui_file *, unsigned char *,
-			     unsigned int);
-
 static void show_print (char *, int);
 
 static void set_print (char *, int);
@@ -846,7 +843,7 @@ print_decimal_chars (struct ui_file *str
 
 /* VALADDR points to an integer of LEN bytes.  Print it in hex on stream.  */
 
-static void
+void
 print_hex_chars (struct ui_file *stream, unsigned char *valaddr, unsigned len)
 {
   unsigned char *p;
@@ -873,6 +870,40 @@ print_hex_chars (struct ui_file *stream,
 	}
     }
   fputs_filtered (local_hex_format_suffix (), stream);
+}
+
+/* VALADDR points to a char integer of LEN bytes.  Print it out in appropriate language form on stream.  
+   Omit any leading zero chars.  */
+
+void
+print_char_chars (struct ui_file *stream, unsigned char *valaddr, unsigned len)
+{
+  unsigned char *p;
+
+  if (TARGET_BYTE_ORDER == BFD_ENDIAN_BIG)
+    {
+      p = valaddr;
+      while (p < valaddr + len - 1 && *p == 0)
+	++p;
+
+      while (p < valaddr + len)
+	{
+	  LA_EMIT_CHAR (*p, stream, '\'');
+	  ++p;
+	}
+    }
+  else
+    {
+      p = valaddr + len - 1;
+      while (p > valaddr && *p == 0)
+	--p;
+
+      while (p >= valaddr)
+	{
+	  LA_EMIT_CHAR (*p, stream, '\'');
+	  --p;
+	}
+    }
 }
 
 /*  Called by various <lang>_val_print routines to print elements of an
Index: printcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/printcmd.c,v
retrieving revision 1.76
diff -u -p -r1.76 printcmd.c
--- printcmd.c	23 Feb 2004 19:41:47 -0000	1.76
+++ printcmd.c	26 Feb 2004 22:07:15 -0000
@@ -350,6 +350,33 @@ print_scalar_formatted (void *valaddr, s
   LONGEST val_long = 0;
   unsigned int len = TYPE_LENGTH (type);
 
+  if (len > sizeof(LONGEST) &&
+      (TYPE_CODE (type) == TYPE_CODE_INT ||
+       TYPE_CODE (type) == TYPE_CODE_ENUM))
+    {
+      switch (format)
+	{
+	case 'o':
+	  print_octal_chars (stream, valaddr, len);
+	  return;
+	case 'u':
+	case 'd':
+	  print_decimal_chars (stream, valaddr, len);
+	  return;
+	case 't':
+	  print_binary_chars (stream, valaddr, len);
+	  return;
+	case 'x':
+	  print_hex_chars (stream, valaddr, len);
+	  return;
+	case 'c':
+	  print_char_chars (stream, valaddr, len);
+	  return;
+	default:
+	  break;
+	};
+    }
+
   if (format != 'f')
     val_long = unpack_long (type, valaddr);
 

Re: [RFA]: Patch for regression with huge integer

[Andrew Cagney]

> 2004-02-26  Jeff Johnston  <jjohnstn@redhat.com>
> 
>         * valprint.h (print_hex_chars, print_char_chars): New prototypes.
>         * valprint.c (print_hex_chars): Change from static to external.
>         (print_char_chars): New function.
>         * printcmd.c (print_scalar_formatted): For integer and enum types
>         that are longer than LONGEST, perform processing via appropriate
>         print_*_chars routines.

Yes.

Coding nit though, "||" and "&&" go on the lhs, not rhs.

Andrew


> +  if (len > sizeof(LONGEST) &&
> +      (TYPE_CODE (type) == TYPE_CODE_INT ||
> +       TYPE_CODE (type) == TYPE_CODE_ENUM))

Re: [RFA]: Patch for regression with huge integer

[Daniel Jacobowitz]

On Thu, Feb 26, 2004 at 05:16:08PM -0500, Jeff Johnston wrote:
> Ok to commit?  I added a function to print out the char format.  It does 
> not print out leading zero bytes.  Thus, if you set some large integer 
> value to 'a', it would print out just 'a'.

In the future, please send patches to gdb-patches instead.  Thanks.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA]: Patch for regression with huge integer

[Jeff Johnston]

Daniel Jacobowitz wrote:
> On Thu, Feb 26, 2004 at 05:16:08PM -0500, Jeff Johnston wrote:
> 
>>Ok to commit?  I added a function to print out the char format.  It does 
>>not print out leading zero bytes.  Thus, if you set some large integer 
>>value to 'a', it would print out just 'a'.
> 
> 
> In the future, please send patches to gdb-patches instead.  Thanks.
>

Sorry.  Did a reply-all and forgot the original posting was to gdb.

-- Jeff J.