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

J. Johnston
2003-12-13T00:55:13Z

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.