This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] mips: Fix "info registers" output
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