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

["J. Johnston" <jjohnstn at redhat dot 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.