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

Fri Mar 12 14:52:04 CET 2021

On Fri, Mar 12, 2021 at 02:44:19PM +0100, Marek Behun wrote:
> 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.

Right, so we have to things related to floating point right.  I think
the high level problem/answer is hat on 32bit ARM we followed in the
Linux kernel's footsteps and so we have lib1funcs, etc.  We don't do
what I think of as actual floating point math (ie float foo), but
whatever we can do in shifts we do.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210312/4db65cc6/attachment.sig>