• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 7 replies
  • Subscribers 21 subscribers
  • Views 5366 views
  • Users 0 members are here
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