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