I noticed two issues in the ARM port from GNU-ld. It's a special case when the output target is set manually (linker script or command line). When no target output architecture is set, linking of the objects works fine with GNU-ld. Testcase: I used a current project from me which targets a Cortex-M7 (Armv7E-M). GNU-ld is invoked directly within a Makefile, not via GCC. Compiled the source code with the following GCC options: CCFLAGS += -march=armv7e-m CCFLAGS += -mcpu=cortex-m7 Issue #1 - command line with long option "--architecture ARCH" Setting the target output architecture doesn't work with the command line option when using the long format. GNU-ld doesn't recognize the option and aborts with an error. I don't know if this is a real issue or an usage mistake from me when I use the long option instead of the short form. Tried it with... $ arm-none-eabi-ld --architecture armv7e-m arm-none-eabi-ld: Error: unable to disambiguate: --architecture (did you mean ---architecture ?) ...and... arm-none-eabi-ld --architecture=armv7e-m arm-none-eabi-ld: Error: unable to disambiguate: --architecture=armv7e-m (did you mean ---architecture=armv7e-m ?) Works with the short form: $ arm-none-eabi-ld -A armv7e-m Issue #2 - linker script If I don't use the working short form for setting the target output architecture and use a linker script instead with... OUTPUT_ARCH(armv7e-m) ...linking fails with many EABI version mismatches errors: arm-none-eabi-ld: error: source object main.o has EABI version 5, but target main_cm7.elf has EABI version 0 arm-none-eabi-ld: failed to merge target specific data of file main.o The linking fails with GNU-ld, but works when I use GNU-gold instead. An ARM developer community member has also confirmed this behavior. Affected version: 2.36.1.20210621 $ arm-none-eabi-ld --version GNU ld (GNU Arm Embedded Toolchain 10.3-2021.07) 2.36.1.20210621 I currently haven't build GNU ld from the actually source code, so I don't know if these issues are known or already fixed. Will make up this later. The tried version was the binary build from the ARM homepage. References: ARM developer Community: https://community.arm.com/support-forums/f/compilers-and-libraries-forum/52304/arm-none-eabi-ld-cannot-set-target-architecture StackOverflow: https://stackoverflow.com/questions/71188898/gnu-ld-warn-about-mismatching-arm-architecture-version
Created attachment 14426 [details] Proposed patch
(In reply to Johannes (krjdev) Krottmayer from comment #0) Hi Johannes, These are two separate issues, and really should have two separate PRs filed. But never mind, since they should be relatively easy to solve. > OUTPUT_ARCH(armv7e-m) > > ...linking fails with many EABI version mismatches errors: > arm-none-eabi-ld: error: source object main.o has EABI version 5, but target > main_cm7.elf has EABI version 0 > arm-none-eabi-ld: failed to merge target specific data of file main.o There is code in the linker that normally handles this case, but it is tied to using the default architecture. When that is overridden by a linker script, the code is not triggered. Please could you try out the uploaded patch. It should fix both issues. If you are happy with it, I will check it in. Cheers Nick
(In reply to Johannes (krjdev) Krottmayer from comment #0) [Weird - I managed to delete my explanation for issue 1...] > Issue #1 - command line with long option "--architecture ARCH" > > $ arm-none-eabi-ld --architecture armv7e-m > arm-none-eabi-ld: Error: unable to disambiguate: --architecture (did you > mean ---architecture ?) The linker is not sure if you are passing the "--a" option with an argument of "rchitecture" or the "--architecture" option. A bit silly, but it does make more sense when other options are considered. For example should "-omagic" set the OMAGIC flag in the output file or set its output name to "magic" ? Anyway the uploaded patch includes a fix for this problem, so please give it a try.
Would it be possible to get the pre-built binutils with that patch for testing? The problem was reported to me which seems to be this one.
Created attachment 14836 [details] test case This test-case ends with ld: error: source object obj2.o has EABI version 5, but target out.o has EABI version 0 ld: failed to merge target specific data of file obj2.o make: *** [Makefile:4: out.o] Error 1 Nick, could you please check if your patch fixes this? Seems a bit easier than to convince people to test the patch.
(In reply to Stas Sergeev from comment #5) > Created attachment 14836 [details] > test case > > This test-case ends with > > ld: error: source object obj2.o has EABI version 5, but target out.o has > EABI version 0 > ld: failed to merge target specific data of file obj2.o > make: *** [Makefile:4: out.o] Error 1 > > Nick, could you please check if your patch > fixes this? Seems a bit easier than to > convince people to test the patch. It doesn't. :-( But you can fix the problem by rearranging the order of the object files on the link command line: ld -r -o out.o obj2.o obj1.o This will remove the error, although you may still get a warning about obj2.o not having a .note.GNU-stack section. Cheers Nick
(In reply to Nick Clifton from comment #6) > It doesn't. :-( But you can fix the problem by rearranging the order of the > object files on the link command line: Thanks, waiting for the test results from client. In a mean time, if your patch doesn't fix that, then will you provide another patch? Or is this not a bug, or is this not the same bug that was reported here, or what is the status?
(In reply to Stas Sergeev from comment #7) Hi Stas, > In a mean time, if your patch doesn't fix that, > then will you provide another patch? I will try to provide another patch - or an updated version of the original patch. This does depend upon why the original patch fails though... Cheers Nick
The status of this bug is "WAITING". Waiting for what? I provided a test-case and it was confirmed, so please update the status?
(In reply to Stas Sergeev from comment #9) > The status of this bug is "WAITING". > Waiting for what? The results of the tests that you said you were running in comment #7.
(In reply to Nick Clifton from comment #10) > The results of the tests that you said you were running in comment #7. The results were absolutely positive. The suggested work-around works as expected. But why to wait for them? The fact that the work-around worked, is not helpful in fixing the bug itself.
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a79e9a07a0d350031cd491031a756fbaa6a01df0 commit a79e9a07a0d350031cd491031a756fbaa6a01df0 Author: Nick Clifton <nickc@redhat.com> Date: Mon Oct 16 15:48:26 2023 +0100 Fix: GNU-ld: ARM: Issues when trying to set target output architecture PR 28910 * lexsup.c (ld_options): Require that the --architecture option is given exactly two dashes, so that it does not become confused with the -a option.
(In reply to cvs-commit@gcc.gnu.org from comment #12) > The master branch has been updated by Nick Clifton <nickc@sourceware.org>: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=a79e9a07a0d350031cd491031a756fbaa6a01df0 > > commit a79e9a07a0d350031cd491031a756fbaa6a01df0 > Author: Nick Clifton <nickc@redhat.com> > Date: Mon Oct 16 15:48:26 2023 +0100 > > Fix: GNU-ld: ARM: Issues when trying to set target output architecture > > PR 28910 > * lexsup.c (ld_options): Require that the --architecture option is > given exactly two dashes, so that it does not become confused with the -a > option. I don't understand... In comment #6 you said this patch doesn't work, and now you apply it?
(In reply to Stas Sergeev from comment #13) > > * lexsup.c (ld_options): Require that the --architecture option is > > given exactly two dashes, so that it does not become confused with the -a > > option. > > I don't understand... > In comment #6 you said this patch > doesn't work, and now you apply it? In comment #6 I said that the patch does not fix the second problem that you listed. The patch does however fix the first problem (the linker not recognising the --architecture option). So I have gone ahead and applied the part of the patch that fixes this problem. I am now trying to re-investigate the second problem. Unfortunately I can no longer reproduce it. That is, using the test script you supplied, I cannot get the linker to issue any error messages about the EABI versions, regardless of the order in which the object files appear on the command line. Possibly I need to combine your test files with a linker script that defines the output architecture in order to actually trigger the problem ? I will give this a go.
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=fd00374fc73e990b2a1b97a1bab431e0466f5efc commit fd00374fc73e990b2a1b97a1bab431e0466f5efc Author: Nick Clifton <nickc@redhat.com> Date: Mon Oct 16 16:11:49 2023 +0100 Fix: GNU-ld: ARM: Issues when trying to set target output architecture PR 28910 * elf32-arm.c (elf32_arm_merge_private_bfd_data): Do not set output flags if the input flags have not been set.
Right - I cannot reproduce the second bug either - that is, with the full patch applied, everything appears to work. Thus my best guess is that I was wrong in comment #6. I said that the patch did not work, whereas in fact it did work. So I have gone ahead and applied the second half of the patch as well. Stas - if you can find a way to trigger the bug with these patches applied, please feel free to reopen this PR.
(In reply to Nick Clifton from comment #16) > Stas - if you can find a way to trigger the bug with these patches applied, > please feel free to reopen this PR. I tried to reproduce it again (w/o any patches), and just as you said in comment #14, I can't. So not sure what was the actual fix and what does your patch do, but let's hope its all good. :)
This patch somehow has side effects: Since this commit, using a cross compiler to build the Linux parisc or some sh kernels fails: http://toolchain.lug-owl.de/laminar/jobs/linux-parisc-generic-32bit_defconfig/36 + log_execute 'mk all' ionice --class Idle make V=1 CROSS32_COMPILE=hppa-linux- ARCH=parisc CROSS_COMPILE=hppa-linux- INSTALL_MOD_PATH=/var/lib/laminar/run/linux-parisc-generic-32bit_defconfig/36/linux-parisc-generic-32bit_defconfig INSTALL_DTBS_PATH=/var/lib/laminar/run/linux-parisc-generic-32bit_defconfig/36/linux-parisc-generic-32bit_defconfig all [...] [mk all 2023-11-10 19:49:33] # OBJCOPY arch/parisc/boot/compressed/vmlinux.bin [mk all 2023-11-10 19:49:33] hppa-linux-objcopy -R .comment -R .note -S vmlinux arch/parisc/boot/compressed/vmlinux.bin [mk all 2023-11-10 19:49:33] # GZIP arch/parisc/boot/compressed/vmlinux.bin.gz [mk all 2023-11-10 19:49:33] cat arch/parisc/boot/compressed/vmlinux.bin | gzip -n -f -9 > arch/parisc/boot/compressed/vmlinux.bin.gz [mk all 2023-11-10 19:49:34] # LD arch/parisc/boot/compressed/piggy.o [mk all 2023-11-10 19:49:34] hppa-linux-ld -z noexecstack --no-warn-rwx-segments -r --format binary --oformat elf32-hppa-linux -T arch/parisc/boot/compressed/vmlinux.scr arch/parisc/boot/compressed/vmlinux.bin.gz -o arch/parisc/boot/compressed/piggy.o [mk all 2023-11-10 19:49:34] hppa-linux-ld: Error: unable to disambiguate: --format (did you mean ---format ?) [mk all 2023-11-10 19:49:34] make[3]: *** [arch/parisc/boot/compressed/Makefile:75: arch/parisc/boot/compressed/piggy.o] Error 1 [mk all 2023-11-10 19:49:34] make[2]: *** [arch/parisc/boot/Makefile:17: arch/parisc/boot/compressed/vmlinux] Error 2 [mk all 2023-11-10 19:49:34] make[1]: *** [arch/parisc/Makefile:161: bzImage] Error 2 [mk all 2023-11-10 19:49:34] make: *** [Makefile:234: __sub-make] Error 2 http://toolchain.lug-owl.de/laminar/jobs/linux-sh-microdev_defconfig/37 + log_execute 'mk all' ionice --class Idle make V=1 ARCH=sh CROSS_COMPILE=sh-linux- INSTALL_MOD_PATH=/var/lib/laminar/run/linux-sh-microdev_defconfig/37/linux-sh-microdev_defconfig INSTALL_DTBS_PATH=/var/lib/laminar/run/linux-sh-microdev_defconfig/37/linux-sh-microdev_defconfig all [...] [mk all 2023-11-11 04:19:44] # OBJCOPY arch/sh/boot/compressed/vmlinux.bin [mk all 2023-11-11 04:19:44] sh-linux-objcopy -O binary -R .note -R .note.gnu.build-id -R .comment -R .stab -R .stabstr -S -R .empty_zero_page vmlinux arch/sh/boot/compressed/vmlinux.bin [mk all 2023-11-11 04:19:44] # GZIP arch/sh/boot/compressed/vmlinux.bin.gz [mk all 2023-11-11 04:19:44] cat arch/sh/boot/compressed/vmlinux.bin | gzip -n -f -9 > arch/sh/boot/compressed/vmlinux.bin.gz [mk all 2023-11-11 04:19:45] # LD arch/sh/boot/compressed/piggy.o [mk all 2023-11-11 04:19:45] sh-linux-ld -EL -z noexecstack --no-warn-rwx-segments -r --format binary --oformat elf32-sh-linux -T arch/sh/boot/compressed/vmlinux.scr arch/sh/boot/compressed/vmlinux.bin.gz -o arch/sh/boot/compressed/piggy.o [mk all 2023-11-11 04:19:45] sh-linux-ld: Error: unable to disambiguate: --format (did you mean ---format ?) [mk all 2023-11-11 04:19:45] make[3]: *** [arch/sh/boot/compressed/Makefile:59: arch/sh/boot/compressed/piggy.o] Error 1 [mk all 2023-11-11 04:19:45] make[2]: *** [arch/sh/boot/Makefile:40: arch/sh/boot/compressed/vmlinux] Error 2 [mk all 2023-11-11 04:19:45] make[1]: *** [arch/sh/Makefile:170: zImage] Error 2 [mk all 2023-11-11 04:19:45] make: *** [Makefile:234: __sub-make] Error 2
Created attachment 15218 [details] Proposed patch Hi Jan, Please could you try out this supplemental patch ? Cheers Nick
reopening
Got two "green": http://toolchain.lug-owl.de/laminar/jobs/linux-parisc-generic-32bit_defconfig/57 http://toolchain.lug-owl.de/laminar/jobs/linux-sh-microdev_defconfig/38 I have not yet tested whether or not other builds are affected negatively, will queue a complete set of Builds followed by a round of Linux kernel builds. But the first impression is positive. Thanks a lot!
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b0dfd7427be1c022581ea4ff33713e9922294c34 commit b0dfd7427be1c022581ea4ff33713e9922294c34 Author: Nick Clifton <nickc@redhat.com> Date: Mon Nov 13 16:24:19 2023 +0000 GNU-ld: ARM: Issues when trying to set target output architecture PR 28910 * lexsup.c (ld_options): Ensure that the --format option is correctly recognised.
OK, I have applied the patch. I have a suspicion that the problem may exist for other long-format command line options, so I am not going to close this PR just yet. I need to do some more testing first...
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b2a6584d753a4dc94139e98c6998f570ed1e2341 commit b2a6584d753a4dc94139e98c6998f570ed1e2341 Author: Nick Clifton <nickc@redhat.com> Date: Tue Nov 14 11:24:58 2023 +0000 Fix another linker command line option that was not being recognised in its long form. PR 28910 * lexsup.c (ld_options): Ensure that the --mri-script option is correctly recognised.
As I suspected there was another long option which was not being recognised. I have pushed a patch to fix that, and I think that the rest should be OK, so I am closing this PR for now.
All mass compilations of Binutils worked as expected. Linux kernel builds are running, but no other regressions (and parisc and sh are fixed.) Thanks!