Hi Tom, On Tue, Sep 27, 2022 at 8:57 AM Tom Rini <tr...@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 <ade...@google.com> > > Cc: Simon Glass <s...@chromium.org> > > Cc: Tom Rini <tr...@konsulko.com> > > Cc: Nick Desaulniers <ndesaulni...@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.
