This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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 | <the other new ABI bits), or

* if an ABI bit is specified use what it specifies, else if 32-bit ELF
and no ABI bit is specified use old reg names, else (must be 64-bit
ELF and no ABI bit specified) use new reg names.  That only works if
64-bit ELF _always_ encodes o32/o64 binary ABIs properly, though.
(Specifically, if GCC tries to use o64 by default when compiling
64-bit ELF code, and that falls into an assembler that produces a
64-bit ELF binary, and that binary is _not_ properly marked as
o64... then you can't really use this option.)

i think either of those gives you the current state for unmarked
binaries.


cgd

	



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]