[v3,1/3] Use bfd_mach_mips4000 as the default machine type for 64-bit MIPS ABIs.

  If the flags word of an ELF header is empty, _bfd_elf_mips_mach always
returned bfd_mach_mips3000 which is a 32-bit MIPS ABI.  This change
uses bfd_mach_mips4000 if the ELF class identifies a 64-bit binary.

bfd/ChangeLog:

	* elf32-mips.c: Pass "abfd" to "_bfd_elf_mips_mach".
	* elf64-mips.c: Likewise.
	* elfn32-mips.c: Likewise.
	* elfxx-mips.c (_bfd_elf_mips_mach): Read "flags" from ELF header
	in "abfd".  Use "bfd_mach_mips4000" as default machine for 64-bit
	ABIs.
	* elfxx-mips.h (_bfd_elf_mips_mach): Change argument from "flags"
	to "abfd".
---
 bfd/ChangeLog     | 11 +++++++++++
 bfd/elf32-mips.c  |  2 +-
 bfd/elf64-mips.c  |  2 +-
 bfd/elfn32-mips.c |  2 +-
 bfd/elfxx-mips.c  | 11 +++++++----
 bfd/elfxx-mips.h  |  2 +-
 6 files changed, 22 insertions(+), 8 deletions(-)
  

On Tue, 3 Jan 2017, John Baldwin wrote:

> If the flags word of an ELF header is empty, _bfd_elf_mips_mach always
> returned bfd_mach_mips3000 which is a 32-bit MIPS ABI.  This change
> uses bfd_mach_mips4000 if the ELF class identifies a 64-bit binary.

 Since this touches the MIPS port I'll have a look at it in details when I 
am back next week.

 In particular I'm a bit concerned about the inconsistency between n64 and 
n32 it introduces by making one default to `bfd_mach_mips4000' but not the 
other, while both are 64-bit ABIs requiring a 64-bit processor to run. 
Which is also already known at the time `_bfd_elf_mips_mach' is being 
called.  So rather than changing its API entirely perhaps we just need an 
extra `need_64bit' or suchlike extra argument for the callee to select the 
BFD appropriately if the ISA is set incorrectly in the ELF object.

 Also can you please remind me why this is the case in the first place and 
how exactly such ELF objects are annotated, e.g. can we identify (limit 
the handling of) such faulty objects with the EI_OSABI marker for example? 
NB this should be explained in details for posterity in the commit message 
itself.

 Thanks,

  Maciej
  

On Wednesday, January 04, 2017 02:09:17 AM Maciej W. Rozycki wrote:
> On Tue, 3 Jan 2017, John Baldwin wrote:
> 
> > If the flags word of an ELF header is empty, _bfd_elf_mips_mach always
> > returned bfd_mach_mips3000 which is a 32-bit MIPS ABI.  This change
> > uses bfd_mach_mips4000 if the ELF class identifies a 64-bit binary.
> 
>  Since this touches the MIPS port I'll have a look at it in details when I 
> am back next week.
> 
>  In particular I'm a bit concerned about the inconsistency between n64 and 
> n32 it introduces by making one default to `bfd_mach_mips4000' but not the 
> other, while both are 64-bit ABIs requiring a 64-bit processor to run. 
> Which is also already known at the time `_bfd_elf_mips_mach' is being 
> called.  So rather than changing its API entirely perhaps we just need an 
> extra `need_64bit' or suchlike extra argument for the callee to select the 
> BFD appropriately if the ISA is set incorrectly in the ELF object.
> 
>  Also can you please remind me why this is the case in the first place and 
> how exactly such ELF objects are annotated, e.g. can we identify (limit 
> the handling of) such faulty objects with the EI_OSABI marker for example? 
> NB this should be explained in details for posterity in the commit message 
> itself.

The specific use case is that FreeBSD/mips kernels currently write out
process core dumps with the 'flags' field in the ELF header set to zero.
This is true for o32, n64, and n32.  I originally added a workaround in
elfcore_grok_freebsd_* to use the ELF class instead of 'bits_per_word' to
determine the layout of the process info and status core dump notes, but
switched to this approach in reponse to review of the first patch.

I would be fine with making this conditional on ELFOSABI_FREEBSD.  At some
point I will probably fix FreeBSD/mips kernels to set a suitable value
in e_flags (probably just copy it over from the binary) at which point
this workaround would no longer be needed, but that doesn't fix existing
cores.