• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 7 replies
  • Subscribers 22 subscribers
  • Views 5289 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

arm-none-eabi-ld: Cannot set target architecture

krjdev

Hi GNU ld experts!

This question is related to a StackOverflow discussion, how GNU ld handles architecture mismatches.

When the ELF objects are compiled in a different architecture than the target architecture from GNU ld.

Without passing GNU ld a target architecture, GNU ld detects the architecture in the ELF objects and

link the objects in a binary. If there are some mismatches with the object files, then GNU ld refuse the linking

with an error.

Issue #1

It isn't possible to pass the architecture to ARM GNU ld when passing the architecture via command line.

The option will not recognized and GNU ld abort with an error.

Issue #2

When trying to use a linker script and set the output architecture here, it leads in many errors

with mismatching EABI version. I have tried to find a option how to set the target EBAI version with

GNU ld, but currently didn't find the correct option, if this is possible.

On none-ARM architectures like AVR from Microchip (formerly Atmel) there are no issues with GNU ld

when setting the target architecture.

Parents
  • +1 in reply to krjdev

    Thank you for the details. I understand the issue now.

    The ld linker does scan for the OUTPUT_ARCH(armv7e-m) in its list of archs/processors and does find a match for armv7e-m. But when the arch is non-default, the linker fails to correctly set the output format. At this line, if a check: if(in_flags == 0) {elf_flags_init (obfd) = false; return true;} is added, the link can be made to succeed.

    For the non-default (i.e. failing) argument, it marks the output flags as initialized even if the input flags are 0 i.e. not initialized. For the default (i.e. success) case, it does not mark the output flag as initialized if the input flags are 0. The above one-liner check resets the output flag marks the output flag as uninitialized if it finds that the input flags are 0. The link succeeds but I do not know enough to say if this is a problem, or not.

    Note that OUTPUT_ARCH(arm) still works - it correctly sets armv7e-m in the final output binary. If other linkers succeed with force-setting a non-default OUTPUT_ARCH, then this could indicate a problem with ld. I haven't checked ld.gold, or mold, or lld yet.

Reply
  • +1 in reply to krjdev

    Thank you for the details. I understand the issue now.

    The ld linker does scan for the OUTPUT_ARCH(armv7e-m) in its list of archs/processors and does find a match for armv7e-m. But when the arch is non-default, the linker fails to correctly set the output format. At this line, if a check: if(in_flags == 0) {elf_flags_init (obfd) = false; return true;} is added, the link can be made to succeed.

    For the non-default (i.e. failing) argument, it marks the output flags as initialized even if the input flags are 0 i.e. not initialized. For the default (i.e. success) case, it does not mark the output flag as initialized if the input flags are 0. The above one-liner check resets the output flag marks the output flag as uninitialized if it finds that the input flags are 0. The link succeeds but I do not know enough to say if this is a problem, or not.

    Note that OUTPUT_ARCH(arm) still works - it correctly sets armv7e-m in the final output binary. If other linkers succeed with force-setting a non-default OUTPUT_ARCH, then this could indicate a problem with ld. I haven't checked ld.gold, or mold, or lld yet.

Children