public inbox for
 help / color / mirror / Atom feed
* -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

 ram (rwx) : ORIGIN = 0x20000000, LENGTH = 8K
 rom (rx) : ORIGIN = 0x08000000, LENGTH = 64K
 .text : {
 } >rom
 .noinit (NOLOAD) : {
 } >ram
 .data : {
 } >ram AT >rom
 .bss : {
  . = ALIGN(4);
 } >ram


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

gives me the error

/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

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.
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-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= --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.


^ 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).