Re: [RFA] mips 32/64 register/stack fix

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, Apr 22, 2004 at 03:59:38PM -0400, Andrew Cagney wrote:
> >!   if (mips_saved_regsize (tdep) < mips_regsize (gdbarch) &&
> >!       trad_frame_addr_p (info->saved_regs, regnum))
> >!     {
> 
> This doesn't look right, can you post a backtrace?
> 
> The MIPS has [0 .. NUM_REGS) ISA sized registers and [NUM_REGS .. 
> 2*NUM_REGS) ABI sized registers.  So if the caller wants an ABI register 
> it should have passed in that register number.

Personally, I think the mistake is higher up - in mips_regsize or
further.  Look at this:

int
mips_regsize (struct gdbarch *gdbarch)
{
  return (gdbarch_bfd_arch_info (gdbarch)->bits_per_word
          / gdbarch_bfd_arch_info (gdbarch)->bits_per_byte);
}

bits_per_word is based on the BFD architecture, which is based on
EF_MIPS_MACH and EF_MIPS_ARCH.  I don't think it's useful to have
-mcpu=mips64 -mabi=32 code (which is pretty much what Michael's
describing) behave differently from -mcpu=mips1 -mabi=32 code; a native
GNU/Linux GDB has to deal with 32-bit target registers and 32-bit saved
registers in either case.  And that's what you get if you build the
optimal compiler for a 32-bit kernel on a 64-bit processor, which lots
of people do.

It's very easy to reproduce this problem if you have access to anything
that can run a MIPS64 GNU/Linux kernel.  Build an n32 GDB, run it using
--target_board unix/-mabi=32/-mcpu=mips64, IIRC.  I have a collection
of hacks to work around this and they're gross beyond all description,
which is why I tabled them until after I sort through the prologue
analysis issues.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer