Re: [RFA] mips: Fix "info registers" output

[Daniel Jacobowitz <drow@mvista.com>]

On Sun, Mar 10, 2002 at 12:46:46PM -0500, Andrew Cagney wrote:
> >On Sun, Mar 10, 2002 at 11:30:09AM -0500, Andrew Cagney wrote:
> 
> >>Suggest a FIXME and bug report here.  It isn't safe to assume things 
> >>like builtin_type_double is 64 bit.  The code should use the ABI 
> >>independant builtin_type_ieee_BLAH.  But this is a separate bug and not 
> >>your problem :-)
> >
> >
> >builtin_type_double =
> >    init_type (TYPE_CODE_FLT, TARGET_DOUBLE_BIT / TARGET_CHAR_BIT,
> >               0,
> >               "double", (struct objfile *) NULL);
> >
> >
> >  set_gdbarch_double_bit (gdbarch, 64);
> >
> >
> >Why isn't it safe to assume that a double is 64-bit when we explicitly
> >set it that way?  I assume that the builtin types get swapped out when
> >we change gdbarch... yes, they do.  Besides, is MIPS FP actually IEEE? 
> >Oh, I suppose the values probably are and only some of the math isn't.
> 
> Have a look at GCC's -fshort-double option.  I'm not sure how MIPS would 
> respond to it but I suspect it would make everyones head hurt. :-)

I suspect the stabs reader would go insane :)  You'd have two floating
point types with different names but the same size... all sorts of
assumptions would probably get confused.

That wouldn't affect builtin_type_double, though, which we define in
terms of the 64 bits.  Are you saying that should be updated based on
the type of 'double' in the objfile?  I don't really think so, since
'the type associated with the word "double"' isn't necessarily tied to
"what this architecture would normally call a double" and
builtin_type_double is the latter.  MIPS would normally call a 64-bit
FP quantity a double, whatever GCC is up to.

> The ``info registers'' code is both ISA and ABI dependant.  ISA since 
> that determines the raw format of registers (ieee_double_{big,little} 
> not double) - the ABI shouldn't change a MIPS DOUBLE.  ABI since that 
> determins where bits of registers end up being saved on the stack.

Right; the way registers are acquired is both ISA and ABI dependent.  I
don't know that the way they are interpreted afterwards is ABI
dependent...

> >Committed without that last FIXME; I'll add it if it's really
> >necessary
> Er, where's the fire?  With all respect, it is always better to give the 
> other party the chance to respond.

Sorry, no fire.  Perhaps I'm just unconscionably impatient, but the
more almost-entirely-approved patches I have lying around from nine
months ago, the more confused I become.  I'll try to curb myself.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer