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

Cheers,
Sam

Reply via email to