This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH v3 1/3] Use bfd_mach_mips4000 as the default machine type for 64-bit MIPS ABIs.
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
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