[PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build

[Marek Behun]

On Fri, 12 Mar 2021 08:18:44 -0500
Tom Rini <trini at 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.cn at gmail.com> wrote:
> >   
> > > On Fri, Mar 12, 2021 at 3:11 PM Marek Behun <marek.behun at nic.cz> wrote:  
> > > >
> > > > On Fri, 12 Mar 2021 14:48:04 +0800
> > > > Bin Meng <bmeng.cn at gmail.com> wrote:
> > > >    
> > > > > On Fri, Mar 12, 2021 at 2:45 PM Marek Behun <marek.behun at nic.cz> wrote:    
> > > > > >
> > > > > > On Wed, 10 Mar 2021 11:40:42 +0800
> > > > > > Bin Meng <bmeng.cn at gmail.com> wrote:
> > > > > >    
> > > > > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Behún <marek.behun at nic.cz> wrote:    
> > > > > > > >
> > > > > > > > When building with LTO, using -ffunction-sections/-fdata-sections is not
> > > > > > > > useful anymore.
> > > > > > > >
> > > > > > > > Signed-off-by: Marek Behún <marek.behun at 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