Re: [PATCH RFA] small fix to MIPS abi selection/decoding.

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Mar 09, 2002 at 12:02:17PM -0800, cgd@broadcom.com wrote:
> The tc-mips.c patch below addresses this: the default of o32 or o64 is
> selected based on GPR size, which yields the more expected:
> 
> 2,4c2,4
> < foo_mips2.o:     file format elf32-bigmips
> < foo_mips2.o
> < architecture: mips:6000, flags 0x00000010:
> ---
> > foo_mips32.o:     file format elf32-bigmips
> > foo_mips32.o
> > architecture: mips:isa32, flags 0x00000010:
> 7c7
> < private flags = 10001000: [abi=O32] [mips2] [not 32bitmode]
> ---
> > private flags = 50001000: [abi=O32] [mips32] [not 32bitmode]

Before you go ahead and commit this, make Eric and/or Thiemo think
about the long discussion we had w.r.t. this.  I think we had decided
that defaulting to o32 based on MIPS1/MIPS2 made sense (that's
traditional) but defaulting to o32 based on GPR size and including
MIPS32 in it didn't.  In other words, that the check was actually
"correct", or at least as we wanted it.

There's a lot of backwards compatibility bogusity here.

> However, doing this causes the MIPS32 and MIPS64 instruction tests to
> fail in the gas testsuite, with diffs like:
> 
> regexp "^0+000c <[^>]*> 70e80001        maddu   a3,t0$"
> line   "0000000c <text_label+0xc> 70e80001      maddu   a3,a4"
> 
> yes, that's right, marking them O32 caused $8 to be interpreted as a4,
> rather than t0.  (!!  "but, that's supposed to happen if a new abi
> (n32, n64, eabi32 or eabi64 -- _not_ o32 or o64).")
> 
> I tracked this down, and it's caused by a (very) bogus test for the
> ABI in the ELF header flags in mips-dis.c.  That's fixed by the patch
> below, as well.

The other bit looks good to me, though.

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