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

[Kevin Buettner <kevinb@redhat.com>]

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.

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

Kevin