Link problem with Cortex-M33: ld.lld: error: duplicate symbol: __aeabi_memcpy

[Laur59]

Hello
Building a project for a Discovery U5A9 board with the toolchain based on LLVM 20 is now issuing errors at link time. The project builds fine with LLVM 19 based toolchain.
This is the message when linking with -v option
link_with_LLVM-ET-Arm-20.txt

What is looking strange to me is to see:

>>> defined at memcpy-armv7m.S:107

For comparison this is the results with LLVM 19
link_with_LLVM-ET-Arm-19.txt

[smithp35]

Out of interest are you putting -lc and /ArmLLVM20/bin/../lib/clang-runtimes/arm-none-eabi/armv8m.main_hard_fp_exn_rtti/lib/libclang_rt.builtins.a on your link line directly?

I would expect that swapping the order so that -lc comes before libclang_rt.builtins.a should resolve this problem. The clang baremetal driver should use this order.

The underlying problem is that compiler-rt builtins and picolibc both have an implementation of the aeabi runtime. As long as the implementation is complete then this shouldn't be a problem and the first library on the link line will take precedent. From memory I think there's a gap in compiler-rt's implementation that means that an object from each implementation can can be selected, leading to duplicate symbols.

[Laur59]

Out of interest are you putting -lc and /ArmLLVM20/bin/../lib/clang-runtimes/arm-none-eabi/armv8m.main_hard_fp_exn_rtti/lib/libclang_rt.builtins.a on your link line directly?

No, these lines are what ld.lld is adding. I have no -lc in my linker options

[smithp35]

It looks like upstream llvm has swapped the order a few days ago (6th December in f9e11501841fc602488fea78b88910eab7d4d396). We'll have to investigate.

Thanks for the report.

[Laur59]

Yes, I was not sure exactly when this happened as until then the building was alright.
The strange point is that building for Cortex M4 and M7 boards are still working.

[smithp35]

To trigger the problem we need a reference to __aeabi_memcpy (or __aeabi_memcpy4, __aeabi_memcpy8 etc.) and a reference to memcpy with the memcpy reference coming first. I think it also needs a Picolibc implementation of memcpy that has aliases for __aeabi_memcpy and friends.

For a work-around I think adding -fno-builtin-memcpy will be sufficient to suppress the use of __aeabi_memcpy so everything will use memcpy. It will also suppress the compiler's ability to inline memcpy so it isn't ideal.

I think it is also likely that if the object that references memcpy is first on the link line then this will force the correct order.

[Laur59]

I tried adding -fno-builtin-memcpy to the compilation flags. This was not solving the problem.
Reading your previous comment about the -lc, I tried to add it at the link command:

$(TARGET).elf : $(LINKS_LD) $(notdir $(FIRST_HIDE_P)) $(UKOS_COMPONENTS) $(LIBS_FILES) $(TARGET).sig $(TARGET).sig.o
	@echo "Linking $@"
	$(HIDE)$(CC) $(LDFLAGS) \
	$(UKOS_FIRST_P) \
	$(WHOLE_ARCHIVE_START) $(UKOS_COMPONENTS) $(TARGET).sig.o $(WHOLE_ARCHIVE_END) $(LIBS) \
	-lm -lc -o $@

And with it it is linking now.
As this is not breaking the building of the other targets (Cortex M4 M7 and RISC-V), I can use it as a temporary workaround.
Thanks for your hints

[Laur59]

It looks like upstream llvm has swapped the order a few days ago (6th December in f9e11501841fc602488fea78b88910eab7d4d396). We'll have to investigate.

I tried swapping lines 494 and 496 in the file BareMetal.cpp, and this resolves my issue.

Maybe a new patch file coud be added.
0008-Try-swapping-order-of-link-options.patch

[smithp35]

That's one possibility, ideally this is something we can fix upstream. I'll need to leave that in the hands of my colleagues as I'll be out of the office for the next few weeks.

[Laur59]

Fine, then I close the issue and wait that upstream provides a solution.
Meanwhile I use this patch on my local branch.

[voltur01]

Temporary workaround provided #610 before we can fix properly after the holidays.