[RFA]: Patch for regression with huge integer

[Jeff Johnston]

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.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: printcmd.patch
URL: <http://sourceware.org/pipermail/gdb/attachments/20040226/261104b3/attachment.ksh>