On Mon, 8 Mar 2021 15:56:01 +0800 Bin Meng <bmeng...@gmail.com> wrote:
> Hi Marek, > > On Sun, Mar 7, 2021 at 12:26 PM Marek Behún <marek.be...@nic.cz> wrote: > > > > It seems that sometimes (happening on ARM64, for example with > > turris_mox_defconfig) GCC, when linking with LTO, changes the symbol > > names of some functions, for example lib/string.c's memcpy() function to > > memcpy.isra.0. > > > > This is a problem however when GCC for a code such as this: > > struct some_struct *info = get_some_struct(); > > struct some struct tmpinfo; > > tmpinfo = *info; > > emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo. > > memset() can be generated sometimes as well. > > > > This then results in the following linking error: > > .../lz4.c:93: undefined reference to `memcpy' > > .../uuid.c:206: more undefined references to `memcpy' follow > > > > Make memcpy() and memset() visible by using the __used macro to avoid > > this error. > > This sounds like a GCC bug of using -fno-builtin and -flto. Could you > file a bugzilla to GCC people to get some comments? This is not LTO related. -fno-builtin still generates memcpy() call for the following code: typedef struct { int a[40]; char b[50]; int c[60]; } a; void cp(a *d, const a *s) { *d = *s; } when compiled with armv7a-hardfloat-linux-gnueabi-gcc -O2 -fno-builtin -ffreestanding \ -nostdlib -S it produces code push {r4, lr} mov ip, #4096 sub ip, sp, ip str r0, [ip, #4088] mov r2, #452 bl memcpy pop {r4, pc} .size cp, .-cp I don't think this is a bug. Or if it is, it is a wontfix. Just implement memcpy into your code, so that gcc does not have to emit shitstorms of instructions because of assignment operator :) Marek