Re: [RFC]: remove inconsistency in printcmd.c: print_scalar_formatted

["J. Johnston" <jjohnstn@redhat.com>]

Kevin Buettner wrote:
> On Dec 12,  3:36pm, Jeff Johnston wrote:
> 
> 
>>There's some code in print_scalar_formatted() I would like to remove.  
>>It tests if the sizeof the type of the value being printed is greater 
>>than the sizeof of LONGEST and if so, it may attempt to use 
>>extract_unsigned_integer().  If that fails, it prints out the value in hex.
>>
>>There a number of problems with this.  First and foremost is the fact 
>>that it is comparing the sizeof with the host's LONGEST type, not the 
>>target.
> 
> 
> I think this is (sort of) okay.  The assumption that's being made is that
> the space needed to hold the bits on the target will be the same as that
> on the host.  I think gdb has serious problems on host/target combinations
> where this is untrue.
> 
> 
>>The second problem is that extract_unsigned_integer() does the 
>>same size test and returns failure so the call is pointless.
> 
> 
> You mean extract_long_unsigned_integer(), right?  When I studied it
> just now, the call didn't appear to be pointless.  It looks to me
> like the code you're deleting is intended to handle the case where
> the space needed by a LONGEST isn't large enough to hold the target's
> type.
>

Yes, sorry about the name typo.  The extract_long_unsigned_integer() function 
ends up testing the type_size - leading zeroes vs the sizeof(LONGEST).  For most 
floats this will fail because of the biased exponent so it returns false.

   if (len <= (int) sizeof (LONGEST))
     {
       *pval = (LONGEST) extract_unsigned_integer (first_addr,
                                                   sizeof (LONGEST));
       return 1;
     }

   return 0;
}

> 
>>The third 
>>problem is that this code creates an inconsistency in how doubles/floats 
>>are treated in comparison to long double.   All  three of these types 
>>are capable of storing a value greater than  that which can be contained 
>>in a LONGEST.  At present, floats and possibly doubles will pass the 
>>size test and end up calling unpack_long().   True long double doesn't 
>>pass the test and ends up printing in hex.  This problem causes a number 
>>of new errors on ia64 with the latest changes to structs.exp.  The new 
>>testcase uses p/c to print out various types and is not ready for the 
>>hex version of the long double value being printed out.
> 
> 
> I think this is the real problem.  The extract_long_unsigned_integer()
> call attempts to fetch the bits from the type with no conversion
> (other than leading zero removal if the type is overlong), but, if
> I'm not mistaken, unpack_long() attempts to do a type conversion
> and these two approaches to fetching the data definitely yield different
> kinds of results.
> 
> 
>>To remedy the problem, I have removed the code.  I don't think it is 
>>particularly helpful.  I think if the user asks for an integral format, 
>>then they should be prepared to take what that choice entails when 
>>printing a float input. 
> 
> 
> I think you're right.
> 
> Something that I've wanted from time to time is a way to print the
> bits comprising a value as some other type.  E.g, if I have a float,
> I'd like to be be able to print the bits that comprise the float as an
> int (or vice versa).  At first, I thought that was the intent of
> print_scalar_formatted(), but I see now that it's not.  If the value
> is stored in memory, you can do it with the appropriate cast, e.g,
> if ``val'' is of type float, you can do ``print *(int *)&val'', but
> AFAIK, you can't do this for values stored in registers or convenience
> variables.  If we had such a mechanism, then I think we'd need some
> code similar to the chunk that you're deleting.
> 

I suppose new format specifiers could always be added in the future to do just 
what you want.

-- Jeff J.