On Fri, 12 Mar 2021 08:18:44 -0500 Tom Rini <tr...@konsulko.com> wrote:
> On Fri, Mar 12, 2021 at 08:29:05AM +0100, Marek Behun wrote: > > On Fri, 12 Mar 2021 15:19:26 +0800 > > Bin Meng <bmeng...@gmail.com> wrote: > > > > > On Fri, Mar 12, 2021 at 3:11 PM Marek Behun <marek.be...@nic.cz> wrote: > > > > > > > > On Fri, 12 Mar 2021 14:48:04 +0800 > > > > Bin Meng <bmeng...@gmail.com> wrote: > > > > > > > > > On Fri, Mar 12, 2021 at 2:45 PM Marek Behun <marek.be...@nic.cz> > > > > > wrote: > > > > > > > > > > > > On Wed, 10 Mar 2021 11:40:42 +0800 > > > > > > Bin Meng <bmeng...@gmail.com> wrote: > > > > > > > > > > > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Behún <marek.be...@nic.cz> > > > > > > > wrote: > > > > > > > > > > > > > > > > When building with LTO, using > > > > > > > > -ffunction-sections/-fdata-sections is not > > > > > > > > useful anymore. > > > > > > > > > > > > > > > > Signed-off-by: Marek Behún <marek.be...@nic.cz> > > > > > > > > --- > > > > > > > > arch/arm/config.mk | 8 ++++++-- > > > > > > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > > > > > I believe we should also remove --gc-sections. > > > > > > > > > > > > It seems that --gc-sections cannot be removed, otherwise some > > > > > > builds, > > > > > > for example turris_mox_defconfig, fail with > > > > > > > > > > > > LTO u-boot > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(lse-init.o): > > > > > > in function `init_have_lse_atomics': > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/config/aarch64/lse-init.c:44: > > > > > > undefined reference to `__getauxval' > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): > > > > > > in function `__absvdi2': > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:228: > > > > > > undefined reference to `abort' > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvsi2.o): > > > > > > in function `__absvsi2': > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:246: > > > > > > undefined reference to `abort' > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_absvdi2.o): > > > > > > in function `__absvti2': > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:267: > > > > > > undefined reference to `abort' > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): > > > > > > in function `__addvdi3': > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:81: > > > > > > undefined reference to `abort' > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvsi3.o): > > > > > > in function `__addvsi3': > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:92: > > > > > > undefined reference to `abort' > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_addvdi3.o):/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:106: > > > > > > more undefined references to `abort' follow > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): > > > > > > in function `__eprintf': > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: > > > > > > undefined reference to `stderr' > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2152: > > > > > > undefined reference to `stderr' > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): > > > > > > in function `fprintf': > > > > > > /usr/aarch64-unknown-linux-gnu/sys-include/bits/stdio2.h:103: > > > > > > undefined reference to `__fprintf_chk' > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: > > > > > > /usr/lib/gcc/aarch64-unknown-linux-gnu/10.2.0/libgcc.a(_eprintf.o): > > > > > > in function `__eprintf': > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2153: > > > > > > undefined reference to `fflush' > > > > > > /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: > > > > > > /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/libgcc2.c:2154: > > > > > > undefined reference to `abort' > > > > > > > > > > Ouch! How compiler behaves when it comes to LTO and works with all > > > > > these compiler/linker options is really a mystery ... > > > > > > > > OK, it seems that on aarch64 we are actually using system's libgcc :) > > > > > > > > > > Thanks. > > > > > > > Not the internal one. So it seems we need --gc-sections to throw away > > > > garbade that is not used. > > > > > > Needed only when CONFIG_USE_PRIVATE_LIBGCC is off? > > > > Seems that way. > > Well, _and_ we need libgcc for anything too. A quick set of hacks: > diff --git a/Makefile b/Makefile > index d6eda45385c3..af3e03ac9fa0 100644 > --- a/Makefile > +++ b/Makefile > @@ -830,8 +830,6 @@ u-boot-main := $(libs-y) > # Add GCC lib > ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y) > PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a > -else > -PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) > -print-libgcc-file-name`) -lgcc > endif > PLATFORM_LIBS += $(PLATFORM_LIBGCC) > > Shows that turris_mox links just fine without the main gcc, because I > probably misunderstood something a bit ages back when dealing with the > libgcc fun we have. So I'm gonna see if that hack above is actually > just correct for all the other cases. > It depends on whether arch/arm/lib provides all necessary functions for aarch64 as well. lib1funcs.S implements stuff only for 32bit arm. But looking at libgcc for aarch64, it does not seem that it contains things that may be needed for u-boot. Maybe floating point operations with -fsoft-float, but I guess nobody uses this in U-Boot. Although recently I was working on driver for Armada 3720 UART baudrate generator, and the computation may need floating point operations to compute best prescaler parameters. But if we limit ourselves to a predefined set of available baudrates, we can just prepare a table with the needed parameters. Marek
