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

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

cgd@sibyte.com wrote:
>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?

Yes, thats the intention.

>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-)

For 64bit-capable MIPS, there are following ABI's supported by the
disasembler:

o32, o64, n32, n64, eabi32, eabi64.

Eabi is wrt a New ABI, so everything else than o{32,64} should
use new register names.

>It's certainly a change from existing behaviour,

Yes, it's a fix for that. The existing behaviour was introduced
by me, too. :-)

>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]"),

MIPS ELF surely has ABI markings in it's header. It hasn't
_processor_ specific flags by default, which are luckily not
needed to check here.

>this may break a bunch of peoples'
>expectations w.r.t. disassembly output...

Again, current behaviour is broken.


Thiemo