Re: [PATCH] Performance counter opcodes for MIPS R1[02]000

[cgd at sibyte dot com]

I looked over your patch, and found it sensible enough with the
exception of the change:

> 	/opcodes/ChangeLog
> 	(_print_insn_mips): Get distinction between old ABI and new ABI right.

and the related changes in the testsuite (mips4650.d, and mips64.d).


> diff -BurPX /bigdisk/dl/src/binutils-exclude src-orig/opcodes/mips-dis.c src/opcodes/mips-dis.c
> --- src-orig/opcodes/mips-dis.c	Wed May 23 21:09:17 2001
> +++ src/opcodes/mips-dis.c	Sat Jun 16 16:27:19 2001
> [ ... ]
> @@ -524,9 +524,9 @@
>    /* Use mips64_reg_names for new ABI.  */
>    if (info->flavour == bfd_target_elf_flavour
>        && info->symbols != NULL
> -      && (((get_mips_isa(info) | INSN_ISA_MASK) & ISA_MIPS2) != 0)
> +      && ((get_mips_isa(info) & INSN_ISA3) != 0)
>        && ((elf_elfheader (bfd_asymbol_bfd(*(info->symbols)))->e_flags
> -	   & EF_MIPS_ABI2) != 0))
> +	   & (E_MIPS_ABI_O32 | E_MIPS_ABI_O64)) == 0))
>      reg_names = mips64_reg_names;
>    else
>      reg_names = mips32_reg_names;

The notion here is that binaries which ELF and are MIPS3 (or better),
and which don't have O32 or O64 indicated are interpreted as using the
'new' (n32/n64) register names?

I'll admit that I've not been following closely for the last month or
so, but I don't understand why this is "Right."  (If there's another
post on the topic that explains, please just point me to it.  8-)


It's certainly a change from existing behaviour, and given that by
default there are no ABI markings on binaries (that I can see;
certainly e.g. the m4650 test just compiled with a clean binutils
build says "[no abi set]"), this may break a bunch of peoples'
expectations w.r.t. disassembly output...



chris