| Message ID | 20210307042538.21229-38-marek.behun@nic.cz |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | U-Boot LTO (Sandbox + Some ARM boards) | expand |
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. Regards, Bin
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'
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 ... Regards, Bin
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 ... Anyway this is weird. __fprintf_chk is a glibc function, so how it ended here I don't know... I am going to investigate this
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 :) Not the internal one. So it seems we need --gc-sections to throw away garbade that is not used. Marek
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? Regards, Bin
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.
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.
On Fri, 12 Mar 2021 08:18:44 -0500 Tom Rini <trini@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@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. > 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
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@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@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. > > > > 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.
diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 4153f7e371..2b2c6ad2e5 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -15,8 +15,12 @@ CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections -fdata-sections CFLAGS_EFI := -fpic -fshort-wchar LDFLAGS_FINAL += --gc-sections -PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \ - -fno-common -ffixed-r9 + +ifndef CONFIG_LTO +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections +endif + +PLATFORM_RELFLAGS += -fno-common -ffixed-r9 PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \ $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))
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(-)