From mboxrd@z Thu Jan 1 00:00:00 1970 From: cgd@sibyte.com To: ica2_ts@csv.ica.uni-stuttgart.de Cc: binutils@sources.redhat.com Subject: Re: [PATCH] Performance counter opcodes for MIPS R1[02]000 Date: Wed, 20 Jun 2001 20:25:00 -0000 Message-id: References: <20010620195157.C22876@rembrandt.csv.ica.uni-stuttgart.de> X-SW-Source: 2001-06/msg00577.html ica2_ts@csv.ica.uni-stuttgart.de ("Thiemo Seufer") writes: > >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. Why is that The Right Thing? > >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. However, what is the ABI reported by existing binaries marked with no ABI bits set whatsoever? > >It's certainly a change from existing behaviour, > > Yes, it's a fix for that. The existing behaviour was introduced > by me, too. :-) Uh, sort-of. As far as I can tell, the current choice of register names (which you're trying to change) for existing un-marked binaries seems to predate you. The part that i have issue with is e.g. the change you made to mips64.d which does: [...] -0+001c <[^>]*> 48a84807 dmtc2 t0,t1,7 [...] +0+001c <[^>]*> 48a84807 dmtc2 a4,\$9,7 [...] The selection of t0 for that register name, for a binary unmarked with ABI, is a change, and I don't understand why it's correct. > >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. by default, there are no ABI markings on binaries (as far as i can tell, with the current and existing tools). There are fields for such markings, e.g. in flags: /* Code in file uses new ABI (-n32 on Irix 6). */ #define EF_MIPS_ABI2 0x00000020 /* The ABI of the file. Also see EF_MIPS_ABI2 above. */ #define EF_MIPS_ABI 0x0000F000 /* The original o32 abi. */ #define E_MIPS_ABI_O32 0x00001000 /* O32 extended to work on 64 bit architectures */ #define E_MIPS_ABI_O64 0x00002000 /* EABI in 32 bit mode */ #define E_MIPS_ABI_EABI32 0x00003000 /* EABI in 64 bit mode */ #define E_MIPS_ABI_EABI64 0x00004000 However, at least in the current mips-elf and mips64-elf toolchains as far as I can tell, _none of those bits is set by default_ and so objdump says "[no abi set]". That's what i meant above when i said that no ABI is set by default. What your change does is change the disassembly of that case -- for no reason that i've been able to discern. Maybe i'm just missing it in your explanations... Anyway, it also looks like you're ignoring the ABI2 flag, aren't you? Since it indicates n32, i believe that means the new reg names, no? Where the code currently in binutils (with your changes) is: /* 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) && ((elf_elfheader (bfd_asymbol_bfd(*(info->symbols)))->e_flags & EF_MIPS_ABI2) != 0)) reg_names = mips64_reg_names; else reg_names = mips32_reg_names; I believe it's more correct to change that so that either: * instead of EF_MIPS_ABI2, you use (EF_MIPS_ABI2 |