[RFC PATCH 00/10] Improve ARM target's support for LLVM toolchain

Heinrich Schuchardt xypron.glpk at gmx.de
Sun May 21 06:26:42 CEST 2023

Am 20. Mai 2023 22:55:37 MESZ schrieb Sam Edwards <cfsworks at gmail.com>:
>Here is a series of patches aimed at improving support for the LLVM
>toolchain (clang, lld, and to a lesser extent, llvm-objcopy) when
>targeting ARM. This toolchain is a cross-compiler "by default" -- a user
>generally should not need to install anything more to target their board
>of choice if they already have Clang installed. Additionally, Clang has
>a few nice diagnostics that should help appreciably with code quality,
>if Clang starts to be used regularly by a few more U-Boot developers. ;)
>Most of these patches are trivial and as such they should be pretty easy
>to review, but the later patches in the patchset start making some
>pretty big changes to the linker scripts. There are no behavioral
>changes with those (U-Boot should still function the same) but there is
>always the risk of compatibility with some third-party tool or loader
>being broken. Fortunately, I foresee any problems making themselves
>immediately apparent upon testing.
>I have tested booting on sunxi/T113, and building for Raspberry Pi
>(32-bit and 64-bit). The remaining testing efforts should be focused on:
>- Exynos
>- EFI loader (esp. on Lenovo X13s, which Heinrich Schuchardt had
>    mentioned in a previous commit as being fickle)
>- Zynq
>- Rockchip TPL
>- AArch64 SPL
>I'm submitting this as an RFC since this doesn't completely guarantee
>LLVM toolchain compatibility yet; my focus here is mostly on ensuring
>that I haven't caused any regressions in GNU-land. Also, I haven't
>discussed most of these changes before doing them. Perhaps alternate
>approaches to some of these things can be proposed - I'm all ears.
>Outstanding problems are:
>- LLD sometimes puts .hash outside of the image binary area, though this
>  is flagged by binary_size_check
>- The main makefile uses --gap-fill=0xff, which is not supported in
>  llvm-objcopy
>- llvm-objcopy also doesn't appear to speak S-Record; the u-boot.srec
>  target has to be deleted manually
>- llvm-objcopy gets upset at some of the EFI code, since the EFI linker
>  scripts preserve dynamic sections that llvm-objcopy doesn't want to
>  strip off

Hello Sam,

thanks for looking into llvm compatibility.

I guess the documentation and the CI testing would also have to be adjusted.

What about non-ARM architectures?

Could you, please, describe how built with lld so that reviewers can test it.

I find reviewing hard when receiving only 3 out of 10 patches.

Best regards


>Sam Edwards (10):
>  makefile: Fix symbol typo in binary_size_check
>  arm: set alignment properly for asm funcs
>  arm: exclude eabi_compat from LTO
>  arm: add __aeabi_memclr in eabi_compat
>  arm: add aligned-memory aliases to eabi_compat
>  arm: discard .gnu.version* sections
>  arm: efi_loader: discard hash, unwind information
>  arm: efi_loader: move .dynamic out of .text in EFI
>  arm: discard all .dyn* sections
>  arm: migrate away from sections.c
> Makefile                                 |   2 +-
> arch/arm/cpu/armv8/spl_data.c            |   4 +-
> arch/arm/cpu/armv8/u-boot-spl.lds        |  26 ++----
> arch/arm/cpu/armv8/u-boot.lds            |  48 +++--------
> arch/arm/cpu/u-boot.lds                  | 103 +++++++----------------
> arch/arm/include/asm/linkage.h           |   4 +-
> arch/arm/lib/Makefile                    |   3 +-
> arch/arm/lib/eabi_compat.c               |  17 ++++
> arch/arm/lib/elf_aarch64_efi.lds         |   3 +-
> arch/arm/lib/elf_arm_efi.lds             |   3 +
> arch/arm/lib/sections.c                  |  36 --------
> arch/arm/mach-rockchip/u-boot-tpl-v8.lds |  26 ++----
> arch/arm/mach-zynq/u-boot.lds            |  73 +++-------------
> 13 files changed, 96 insertions(+), 252 deletions(-)
> delete mode 100644 arch/arm/lib/sections.c

More information about the U-Boot mailing list