[PATCH] Makefile: Disable PLATFORM_LIBGCC for LLVM toolchain

[Alistair Delva]

Hi Tom,

On Tue, Sep 27, 2022 at 8:57 AM Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Sep 26, 2022 at 08:47:47PM +0000, Alistair Delva wrote:
>
> > The LLVM toolchain does not have or need libgcc, so do not require
> > it to exist on the library path. Even if "-print-libgcc-file-name"
> > returned the empty string, -lgcc would be specified.
> >
> > This leaves CONFIG_USE_PRIVATE_LIBGCC alone because I did not have
> > a target/toolchain combination available for testing.
> >
> > Signed-off-by: Alistair Delva <adelva at google.com>
> > Cc: Simon Glass <sjg at chromium.org>
> > Cc: Tom Rini <trini at konsulko.com>
> > Cc: Nick Desaulniers <ndesaulniers at google.com>
> > ---
> >  Makefile | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Makefile b/Makefile
> > index 8af67ebd63..af06b7aa19 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -874,8 +874,10 @@ u-boot-main := $(libs-y)
> >  ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y)
> >  PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a
> >  else
> > +ifneq ($(cc-name),clang)
> >  PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name`) -lgcc
> >  endif
> > +endif
> >  PLATFORM_LIBS += $(PLATFORM_LIBGCC)
> >
> >  ifdef CONFIG_CC_COVERAGE
>
> So this one isn't quite right, and will result in some platforms /
> architectures just failing to build as the handful of functions we get
> provided by CONFIG_USE_PRIVATE_LIBGCC end up being missing.
>
> It's also the case that this is a badly named option, and something we
> really should figure out how to remove and then always provide the
> required functions for. What configuration did you end up having this
> problem on exactly?

We have CI set up for qemu_arm64_defconfig, qemu-x86_64_defconfig,
am57xx_evm_defconfig and rock-pi-4-rk3399_defconfig. I think all were
affected, since they don't use CONFIG_USE_PRIVATE_LIBGCC, so they all
hit this fallback.

AFAIK, for a long time, Android used an LLVM toolchain built with some
workarounds such as knowledge of a corresponding GCC-based toolchain,
so -print-libgcc-file-name could provide a path to libgcc.a. However,
our newer toolchains no longer do this and the symbols are either
automatically provided or provided by compiler-rt. In U-Boot's case, I
don't think our targets ever required libgcc but because the
fall-through expands to "-L . -lgcc" when -print-libgcc-file-name
returns the empty string, the link will fail because it will look for
libgcc but not find it.

Alistair.