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