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

[Tom Rini]

On Mon, May 22, 2023 at 12:39:04PM +0200, Michal Simek wrote:
> Hi
> 
> On 5/21/23 06:59, Sam Edwards wrote:
> > On 5/20/23 22:26, Heinrich Schuchardt wrote:
> > > Hello Sam,
> > 
> > Hi Heinrich! Good to hear from you.
> > 
> > > I guess the documentation and the CI testing would also have to be adjusted.
> > 
> > Ah, yeah, those are going to be big things for me to look at when this
> > series starts to mature out of the RFC phase. CI is definitely important
> > so that the hard-won compatibility doesn't just decay away. :)
> > 
> > > What about non-ARM architectures?
> > 
> > If there's a groundswell of demand for building U-Boot on LLVM, I'd be
> > willing to collaborate with others on getting the other architectures up
> > to parity with GNU. But since the linker scripts, relocation thunks,
> > sections, and whatnot are all arch-specific, I'm only focusing on ARM
> > for now (which is both the arch I need and one of the more common ones).
> > 
> > Is there a particular arch you'd like to see next? It seems everything
> > U-Boot supports is supported by LLVM, except for Microblaze, NIOS2, and
> > SH.
> > 
> > > Could you, please, describe how built with lld so that reviewers can test it.
> > 
> > I've been building with:
> > 
> > nice make CC='clang --target=armv7l-none-eabi' \
> >    LTO_FINAL_LDFLAGS=-fuse-ld=lld LD=ld.lld OBJCOPY=llvm-objcopy
> > 
> > ...though mostly at this stage I'm just hoping for folks to confirm that
> > this patchset causes no regressions in their existing GNU environments.
> > (Feedback from LLVM-land would be appreciated nonetheless, though!!!)
> 
> Dockerfile in repo as I see is using 3 toolchain categories.
> 1. llvm deb repo
> 2. kernel.org
> 3. others - xtensa/arc
> 
> For CI loop you should pretty much provide a way how to get toolchain.
> That's why would be good to figure it out and then I am happy to take a look
> at changed you have done for Zynq.
> Definitely nice to see this happening and I expect more warnings will be
> visible  and they should be fixed.

So, we can trivially add lld to the Dockerfile, it's just listing lld-16
in the install list.  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.  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.

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230522/d78fb66c/attachment.sig>