[Bug ld/17219] ld/mips: can no longer build libstdc++ (gcc 4.8/4.9)
https://sourceware.org/bugzilla/show_bug.cgi?id=17219 Matthew Fortune changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |matthew.fortune at imgtec dot com --- Comment #4 from Matthew Fortune --- (In reply to Aaro Koskinen from comment #3) > I get similar errors with release 2.25 binutils. Trying to cross-build MIPS > GCC configured with --with-float=soft fails miserably. With hard float there > is no issues (or binutils 2.24 with soft float). Apparently 2.25 binutils > require some additional flags which GCC 4.9 fails to pass? > > Is there any simple workaround for this? This is a compiler driver issue. The LD failures relating to relocations are somewhat strange but I believe they are not the important part here. The ABI problems from the assembler warnings are the root cause. I've put together a backport of minimal GCC driver changes for the GCC 4.9 branch and that is pretty much the only way to resolve this. The new floating-point ABI checks in the assembler unfortunately couldn't be seamless for everything and soft-float is the case that takes most of the pain. With the GCC patch in place I managed to build a GCC 4.9 (branch) + binutils 2.25 (branch) soft-float toolchain. I'll post the patch to GCC at some point tomorrow and try to remember and update this ticket with a link. The patch should apply cleanly to any GCC 4.9 release so will have to be ported by a distribution maintainer if anyone wants any of the already released GCC 4.9.x compilers alongside binutils 2.25 onwards. I will look at a similar patch for GCC 4.8 if there is sufficient call for that alongside binutils 2.25. Sorry for not getting to the GCC 4.9 patch sooner, I knew about it and never quite got to doing it. -- 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
[Bug gas/18401] New: MIPS -march=xlp results in inconsistent ISA markers
https://sourceware.org/bugzilla/show_bug.cgi?id=18401 Bug ID: 18401 Summary: MIPS -march=xlp results in inconsistent ISA markers Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: matthew.fortune at imgtec dot com Target Milestone: --- When using -march=xlp the assembler will mark an object with MIPS64 in the ELF flags but will mark it (correctly) with MIPS64R2. This is because the XLP CPU is marked as MIPS64R2 with XLR as the processor. The processor is used to determine the BFD arch and the BFD arch then sets the e_flags. However, the architecture in the .MIPS.abiflags uses the ISA rather than the processor. The simple fix would be to lie and represent the XLP as a MIPS64 but it would be better to update the e_flags to be MIPS64R2 instead. -- 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
[Bug gas/18401] MIPS -march=xlp results in inconsistent ISA markers
https://sourceware.org/bugzilla/show_bug.cgi?id=18401 --- Comment #3 from Matthew Fortune --- (In reply to Nick Clifton from comment #2) > Hi Matthew, > > Will something like the uploaded patch work ? (Caveat: I am not a MIPS > expert, so there may be something that I have missed). > > Cheers > Nick Thanks for the patch but I'm afraid it will just shift the problem from XLP to XLR. There is also a second inconsistency that can occur relating to the octeon+ architecture. The problem cases appear to be where we have an architecture that has extended the base and either not been represented in the e_flags (octeon+) or the same architecture extension has been used on cores with different base architectures (xlp vs xlr). I think I need to go through and evaluate all the architectures and see whether there are any other problem cases. I am half tempted to just relax the linker check for the problem cases but if they can be fixed properly then that would be best of course. I'm going to try and dig through this in the next day or so but may get side-tracked. thanks, Matthew -- 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
[Bug gas/18401] MIPS -march=xlp results in inconsistent ISA markers
https://sourceware.org/bugzilla/show_bug.cgi?id=18401 Matthew Fortune changed: What|Removed |Added Attachment #8311|0 |1 is obsolete|| --- Comment #5 from Matthew Fortune --- 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
[Bug gas/18401] MIPS -march=xlp results in inconsistent ISA markers
https://sourceware.org/bugzilla/show_bug.cgi?id=18401 --- Comment #7 from Matthew Fortune --- (In reply to cvs-com...@gcc.gnu.org from comment #6) > The master branch has been updated by Nick Clifton : Thanks Nick. I ran out of steam after trying to get my head around the right kind of fix. > * ld-mips-elf/mips-elf-flags.exp: Add more ISA conflict tests. I'd forgotten this .exp existed! I'll look through this when I get chance and see if there are any other cases worth testing. Matthew -- 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
[Bug gas/21219] mips gas 2.26 report error:opcode not supported on this processor: mips32r2 (mips32r2) `mttc0 $0,$25,1'
https://sourceware.org/bugzilla/show_bug.cgi?id=21219 Matthew Fortune changed: What|Removed |Added CC||matthew.fortune at imgtec dot com --- Comment #1 from Matthew Fortune --- Created attachment 9881 --> https://sourceware.org/bugzilla/attachment.cgi?id=9881&action=edit proposed fix I have seen this before (and forgotten it without reporting a bug!). I believe the origin of this is actually with the new .module directive support that I added quite a long time ago. The default enabled ASEs for any given architecture are lost before they can be applied. Proposed patch is attached. -- 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
