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

J. Johnston
2004-01-19T22:23:36Z

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