From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 12 Mar 2021 08:52:04 -0500 Subject: [PATCH u-boot 37/39] ARM: don't use -ffunction-sections/-fdata-sections with LTO build In-Reply-To: <20210312144419.0623f76b@nic.cz> References: <20210307042538.21229-1-marek.behun@nic.cz> <20210307042538.21229-38-marek.behun@nic.cz> <20210312074520.7e4e31ba@nic.cz> <20210312081119.1aed4ae9@nic.cz> <20210312082905.531c6ce1@nic.cz> <20210312131844.GT1310@bill-the-cat> <20210312144419.0623f76b@nic.cz> Message-ID: <20210312135204.GV1310@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Mar 12, 2021 at 02:44:19PM +0100, Marek Behun wrote: > On Fri, 12 Mar 2021 08:18:44 -0500 > Tom Rini 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 wrote: > > > > > > > On Fri, Mar 12, 2021 at 3:11 PM Marek Behun wrote: > > > > > > > > > > On Fri, 12 Mar 2021 14:48:04 +0800 > > > > > Bin Meng wrote: > > > > > > > > > > > On Fri, Mar 12, 2021 at 2:45 PM Marek Behun wrote: > > > > > > > > > > > > > > On Wed, 10 Mar 2021 11:40:42 +0800 > > > > > > > Bin Meng wrote: > > > > > > > > > > > > > > > On Sun, Mar 7, 2021 at 12:26 PM Marek Beh?n wrote: > > > > > > > > > > > > > > > > > > When building with LTO, using -ffunction-sections/-fdata-sections is not > > > > > > > > > useful anymore. > > > > > > > > > > > > > > > > > > Signed-off-by: Marek Beh?n > > > > > > > > > --- > > > > > > > > > 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: