From: Tobias Schramm <tobias.schramm@go-e.co>
To: gcc-help@gcc.gnu.org
Subject: -flto causes `undefined reference` for gcc builtins
Date: Mon, 13 Jun 2022 17:29:14 +0200 [thread overview]
Message-ID: <CAD+ESQfzHFPMSrws2vL09KwM3ZynxsqqGJhBF7KrhDycfjN3Mw@mail.gmail.com> (raw)
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
reply other threads:[~2022-06-13 15:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD+ESQfzHFPMSrws2vL09KwM3ZynxsqqGJhBF7KrhDycfjN3Mw@mail.gmail.com \
--to=tobias.schramm@go-e.co \
--cc=gcc-help@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).