On Tue, Sep 27, 2022 at 12:41:15PM -0400, Tom Rini wrote: > On Tue, Sep 27, 2022 at 09:29:51AM -0700, Alistair Delva wrote: > > 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. > > OK, that sounds familiar now that you say it, and part of why rpi_arm64 > + LLVM isn't part of my local testing loop. I believe I had been > thinking the best path forward was to port ashldi3.S and friends from > arch/arm64 in the Linux kernel over, so that USE_PRIVATE_LIBGCC (which > is a bad name!) could also be select'd on CONFIG_ARM64. That would just > leave x86, which just needs a div64 implementation for 64bit? I'm not > entirely sure. > > All of that said, it might also be the case we don't need the fallback > to using libgcc at all, in most cases? If you're able to build and test > those platforms with it disabled, it might well be the case that we > just don't need the fallback anymore, and a world build with that just > removed would help figure out if that's true.
OK, another new test build, a look at the kernel, and I see a better path forward than it used to be at least. It would be best to: - Port the kernel's current GENERIC_LIB_*DI3 functions - Rename USE_PRIVATE_LIBGCC in U-Boot / drop it, depending on the location (arch/arm/lib/Makefile should just include ashldi3.o and friends on !ARM64). - Port the kernel's arch/powerpc/boot/crtsavres.S for PowerPC which is fairly straight forward looking, even if you aren't a PowerPC person This would be the way forward to drop trying to use libgcc directly, I believe. -- Tom
signature.asc
Description: PGP signature
