This is the mail archive of the
binutils@sourceware.org
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.
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: John Baldwin <jhb at FreeBSD dot org>
- Cc: "Maciej W. Rozycki" <macro at imgtec dot com>, gdb-patches at sourceware dot org, binutils at sourceware dot org
- Date: Wed, 4 Jan 2017 02:09:17 +0000 (GMT)
- Subject: Re: [PATCH v3 1/3] Use bfd_mach_mips4000 as the default machine type for 64-bit MIPS ABIs.
- Authentication-results: sourceware.org; auth=none
- References: <20170103184341.58346-1-jhb@FreeBSD.org> <20170103184341.58346-2-jhb@FreeBSD.org>
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