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

Sam Edwards cfsworks at gmail.com
Mon May 22 21:59:33 CEST 2023

Hi Tom,

On 5/22/23 09:30, Tom Rini wrote:
> I think objcopy is a bit of a stretch at this
> point and it's not clear from the above if you're also making use of the
> assembler.

I agree, since getting llvm-objcopy to play nice with this currently 
requires that I make a handful of small hack edits to the makefiles. It 
does offer a great advantage over GNU's objcopy in that it doesn't balk 
at ELFs from a foreign arch, but I'm only supporting it 
"opportunistically" right now.

I do make use of LLVM's assembler, but LLVM bundles its assembler inside 
the Clang binary (`clang -cc1as` and/or just pass .S files to Clang) 
rather than installing a separate program. This is not to be confused 
with `llvm-as` which is for bitcode/IR manipulation only. But in 
general, if you're using Clang, you're also using the LLVM assembler.

> We might also want to look at backporting
> scripts/Makefile.clang from the current kernel build system and then
> adapting the "guess the --target argument" logic based on CONFIG_$ARCH
> rather than ARCH= (which we don't use).  That would also solve the LTO
> problem as that's a result of us missing some flags that the kernel has
> as LLVM+LTO (logically) requires LLVM LD not GNU LD.

Having something like Linux's `LLVM=1` to enable LLVM would be ideal, I 
think. I probably won't be doing that backporting in this patch series 
since my goal for now is just to fill in some of the pitfalls for people 
like me who are too stubborn to install a GNU toolchain.

> At that point, and once the EFI guid_t warning is resolved to everyones
> satisfaction we can put qemu_arm* + clang in the CI loop, to catch new
> warnings there.  I've already got clang + Pi in my CI loop, but that
> doesn't fail on warnings.

Do you mean, on the current master branch, and only Clang (no LLD)? I'm 
in favor, but since a few of the patches in this series (#3-5) are to 
support some of the libcalls that LLVM's codegen likes to emit, I'd be 
surprised if that worked on all targets. Feel free to pull whatever 
necessary patches of mine here into your own series though. :)


More information about the U-Boot mailing list