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

Tom Rini
2023-05-22T15:30:17Z

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

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

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