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

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

Ping.  Could we continue discussing this topic and come to some form of 
resolution?  The new additional ia64 test failures are annoying.

-- Jeff J.


J. Johnston wrote:
> 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.
> 
>