* -flto causes `undefined reference` for gcc builtins
@ 2022-06-13 15:29 Tobias Schramm
0 siblings, 0 replies; only message in thread
From: Tobias Schramm @ 2022-06-13 15:29 UTC (permalink / raw)
To: gcc-help
Hey everyone,
I'm currently wondering about some peculiar behaviour of -flto.
Compiling the following code test.c
#include <string.h>
static char strbuf[32] __attribute__((used));
void reset_handler(void) {
memset(strbuf, 0, sizeof(strbuf));
}
using the boilerplate linker script test.lds
ENTRY(reset_handler)
MEMORY
{
ram (rwx) : ORIGIN = 0x20000000, LENGTH = 8K
rom (rx) : ORIGIN = 0x08000000, LENGTH = 64K
}
SECTIONS
{
.text : {
*(.text*)
*(.rodata*)
} >rom
.noinit (NOLOAD) : {
*(.noinit*)
} >ram
.data : {
*(.data*)
*(.ramtext*)
} >ram AT >rom
.bss : {
*(.bss*)
. = ALIGN(4);
} >ram
}
via
arm-none-eabi-gcc -flto -c test.c -o test.o
arm-none-eabi-gcc-ar -flto r test.a test.o
arm-none-eabi-gcc -flto -nostartfiles -Wl,-\( -Wl,-lc -Wl,-lgcc -Wl,-lnosys
test.a -Wl,-\) -o test.elf -T test.lds
gives me the error
/usr/lib/gcc/arm-none-eabi/12.1.0/../../../../arm-none-eabi/bin/ld:
/tmp/ccsFzvhr.ltrans0.ltrans.o: in function `reset_handler':
<artificial>:(.text+0x14): undefined reference to `memset'
collect2: error: ld returned 1 exit status
To my surprise this does not happen when linking test.o directly without
wrapping it into an archive first:
arm-none-eabi-gcc -flto -nostartfiles -Wl,-\( -Wl,-lc -Wl,-lgcc -Wl,-lnosys
-Wl,-\) test.o -o test.elf -T test.lds
This behaviour does only show up when using link time optimization. If I
run above commands without -flto memset is found and linked correctly. Also
this does not seem to happen on x86, I was not able to reproduce it there.
Additionally the problem also disappears while still using LTO when adding
-fno-builtin to the gcc command line, making me suspect that this is
somehow related to gcc's substitution of builtins.
Is this expected behaviour and am I misunderstanding how symbol lookup at
link time works? I would expect ld to find memset in libc at link time
since it is contained in a group together with test.a.
The version of GCC I'm using is
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/12.1.0/lto-wrapper
Target: arm-none-eabi
Configured with: /build/arm-none-eabi-gcc/src/gcc-12.1.0/configure
--target=arm-none-eabi --prefix=/usr --with-sysroot=/usr/arm-none-eabi
--with-native-system-header-dir=/include --libexecdir=/usr/lib
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch
--disable-nls --disable-shared --disable-threads --disable-tls
--with-gnu-as --with-gnu-ld --with-system-zlib --with-newlib
--with-headers=/usr/arm-none-eabi/include
--with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc
--with-isl --with-libelf --enable-gnu-indirect-function
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='Arch Repository' --with-bugurl=
https://bugs.archlinux.org/ --with-multilib-list=rmprofile
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Arch Repository)
Any input on why I'm seeing this behaviour will be highly appreciated, I
suspect I'm just missing something here, though I was unable to find
anything in particular on this issue online.
Cheers,
Tobias
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2022-06-13 15:29 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-13 15:29 -flto causes `undefined reference` for gcc builtins Tobias Schramm
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).