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

[Andrew Cagney <cagney at gnu dot org>]

Note this tipo:

> > > >   else if (regnum > NUM_REGS
> >  >= NUM_REGS


> > > This change to mips_register_type conveys the fact that we've only got
> > > 32 bits of data.  But we'll choose to print (in info registers) a
> > > 64-bit wide field for each GPR if the binary is tagged E_MIPS_ARCH_64 |
> > > E_MIPS_ABI_EABI32, and a 32-bit field if it's tagged E_MIPS_ARCH_2 |
> > > E_MIPS_ABI_EABI32.  Conceptually, I think we're interested in some
> > > combination of the available register size (-> a property of the target)
> > > and the size of registers known to the inferior program (-> unclear mix
> > > of its ABI and ISA).
> >
> >
> >
> > It does?  With the above it should always print a 32-bit GPR reflecting the 32-bit ABI.  If you think it should display something else, look at user-regs which lets you implement registers using the frame register values (something psuedo registers can't handle).
>
>
> I've got a build -- I'll try your patch and let you know how it behaves.
> Are there any particular things you'd like me to check (eg. info reg),
> aside from the problem that got me on this in the first place?

See daniel's follow up:

> It makes decisions based on mips_regsize.  See print_gp_register_row.
> So does mips32_heuristic_proc_desc; which has probably been converted
> incorrectly at some point in the past, since it takes "8 - mips_regsize
> (current_gdbarch)" and wants 4 for N32.  I think that whole block of
> code is bogus.
>
> Hmm, I was just using print_gp_register_row as an example - but it
> turns out to be the only example.  Only the two functions above and
> mips_register_type reference mips_regsize now - and a bunch of NetBSD
> specific code which is almost certainly wrong.  With the functions
> renamed, I guess it'll be much easier to spot the errors.

Andrew