Hi Boyan,

Till 2.10 if we use LD=aarch64-none-elf-ld directly as build command parameter there was no problem with the build but with ENABLE_LTO patch we got build problems. Are there any generic recommendations on what to use for LD variable (LD=aarch64-none-elf-gcc & LD=aarch64-none-elf-ld) and any plan further in upstream to fix this issue for ENABLE_LTO case.

Regards, Maheedhar.

-----Original Message----- From: Boyan Karatotev via TF-A tf-a@lists.trustedfirmware.org Sent: Monday, January 6, 2025 12:58 PM To: tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Linker errors with ENABLE_LTO and LD overriding

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.

Hi Maheedhar,

...

Build command : make -j12 CC=aarch64-none-elf-gcc LD=aarch64-none-elf-ld CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp RESET_TO_BL31=1 DEBUG=1 ZYNQMP_CONSOLE=dtb bl31> arm-trusted-

firmware$

...

aarch64-none-elf-ld --version

GNU ld (GNU Binutils) 2.42.0.20240620

arm-trusted-firmware$ aarch64-none-elf-gcc --version

aarch64-xilinx-elf-gcc.real (GCC) 13.3.0

Have you tried with `LD=aarch64-none-elf-gcc`? That built for me. Inspecting the top level Makefile seems to suggest LTO will only work when gcc is used as the linker and nothing else. Do you need to use ld directly? LTO seems underused so stuff might be broken (I found https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/33984 recently).

Cheers, Boyan -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org

Hi Maheedhar,

I think Boyan’s analysis and advice is right on both counts, and it’s likely `ENABLE_LTO` was not being enabled even with the patch.

LTO has also only ever been supported by linking via GCC. The build system is capable (as of relatively recently) of determining the proper toolchain automatically, so for your case you can omit `CC`, `LD` and `CROSS_COMPILE` entirely and it should automatically pick up the correct linker.

We (Arm) generally try to avoid touching platforms that we can’t ourselves test directly, but if you need assistance with getting this working then I can help to get it building at least.

Chris

From: Boyan Karatotev Boyan.Karatotev@arm.com Date: Monday, 6 January 2025 at 09:43 To: Bollapalli, Maheedhar Sai MaheedharSai.Bollapalli@amd.com, tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Cc: Simek, Michal michal.simek@amd.com, Chris Kay Chris.Kay@arm.com Subject: Re: [TF-A] Re: Linker errors with ENABLE_LTO and LD overriding Hi Maheedhar,

Till 2.10 if we use LD=aarch64-none-elf-ld directly as build command parameter there was no problem with the build but with ENABLE_LTO patch we got build problems.

Ah right I see. Well, if I'm reading the mailing list thread on the patch you linked correctly, before that patch ENABLE_LTO in platform.mk wouldn't have had any effect. So perhaps it was never building with ENABLE_LTO? I tried it locally on v2.10 with ENABLE_LTO on the commandline and the same error came up.

So by the sounds of it ENABLE_LTO is broken anyway. @Chris, any ideas?

Are there any generic recommendations on what to use for LD variable (LD=aarch64-none-elf-gcc & LD=aarch64-none-elf-ld) and any plan further in upstream to fix this issue for ENABLE_LTO case.

I'm pretty sure that the intention is that if you want LTO, then LD=aarch64-none-elf-gcc is the only one that should work. I'll let Chris confirm.

Boyan