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

[John Baldwin <jhb at freebsd dot org>]

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.

-- 
John Baldwin