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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2885 bytes --]

On Mon, May 22, 2023 at 01:59:33PM -0600, Sam Edwards wrote:
> 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.

Ah, ok.

> > 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.

It honestly shouldn't be too much work to just backport that file (and
move/remove some of the logic we have scattered elsewhere instead).

> > 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. :)

The reason it's not in CI right now is that there's compiler warnings,
due to the EFI guid_t alignment thing that's being discussed in another
thread.  I am running (and so booting and running pytest) in my CI loop
clang-built U-Boot for Pi 3 (32bit and 64bit) and a few other targets
too.  But there's also certainly room to improve and I think some of the
issues you've addressed here are why other targets for example are too
large to boot.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]