https://sourceware.org/bugzilla/show_bug.cgi?id=18401
Matthew Fortune <matthew.fortune at imgtec dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #8311|0 |1
is obsolete| |
--- Comment #5 from Matthew Fortune <matthew.fortune at imgtec dot com> ---
Created attachment 8550
--> https://sourceware.org/bugzilla/attachment.cgi?id=8550&action=edit
Initial proposed fix
This patch is at least the start of a fix for this issue. The problem with the
XLP is that it is described as an 'XLR' in the e_flags machine info which is a
MIPS64 not a MIPS64R2 but the abiflags correctly represents the fact it is a
MIPS64R2. Similar things happen for octeon+ where it has no e_flags
representation (only octeon) but is correctly reported in abiflags.
The solution I propose is that we allow the abiflags information to represent
the same or newer isa/arch than can be inferred from the e_flags data. This
glosses over the subtle inconsistencies here and allows for future extensions
to eventually migrate to abiflags.
There are however a few other options for fixing this issue such as adding new
BFD mach entries for the inconsistent ISAs and adding more EF_MACH entries.
There is a limit to how far this scales though as we will run out of EF_MACH
values eventually so the proposed fix still stands.
I have not done any new tests for this but we need at the very least a simple
single object test for every supported arch and ideally a dual input link test
to combine all pairs of architectures that are related by ISA extension.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
