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
signature.asc
Description: PGP signature