Re: GDB broken on MIPS targets with unmarked binaries

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Jun 07, 2002 at 03:55:11PM -0400, Andrew Cagney wrote:
> >
> >How about setting something in each header that redefines
> >REGISTER_VIRTUAL_TYPE, instead?  I think that's much clearer, and when
> >we multi-arch the targets which do this it will transition more
> >naturally to setting it at gdbarch_init time.  gdbarch_data() is a very
> >nice tool, but this is the wrong kind of nail, IMO.
> >
> >I'm testing this patch.  Yes, it's a little bit of a step backwards for
> >multi-arching, but I still think it's correct; rather than "reverse
> >engineer the header files to figure out the default", let's have the
> >header files tell us what it is.
> >
> >It works fine in my testing; OK to commit, or would you prefer a
> >different way?
> 
> try something like:
> 
> -/* Do not use "TARGET_IS_MIPS64" to test the size of floating point 
> registers */
> -#ifndef FP_REGISTER_DOUBLE
> -#define FP_REGISTER_DOUBLE (REGISTER_VIRTUAL_SIZE(FP0_REGNUM) == 8)
> -#endif
> 
> #define FP_REGISTER_DOUBLE mip_fp_register-double ()
> 
> mips_fp_register_double ()
> {
>   if (current_gdbarch->tdep->fp_register_double < 0)
>     ...->fp_register_double = REGISTER_VIRTUAL_SIZE(FP0_REGNUM) == 8;
>   return gdbarch->tdep->fp_register_double;
> }
> 
> And:
> 
> -      tdep->mips_fp_register_double = (REGISTER_VIRTUAL_SIZE 
> (FP0_REGNUM) == 8);
> 
>   tdep->mips_fp_register_double = -1;
> 
> It delays the computation until it is needed.  It also happens to keep 
> the old code working without having to add more macros :-)

Doesn't work.  It's referenced in creating the register cache, which is
still before we have an architecture.  We need to know this information
earlier.  Any other ideas, or is my original patch OK?

By the way, I think the existing default: case in that switch is pretty
pointless anyway.  Note that it selects an arbitrary number of argument
registers.  It doesn't work when all the tools are configured mips-elf
(default to O32), which is why I suggested some time ago that we just
default to O32 in that configuration at least... that would make the
test numbers suck a bit less, and reduce the black magic factor a bit.

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