On Mon, 8 Mar 2021 15:56:01 +0800 Bin Meng bmeng.cn@gmail.com wrote:
Hi Marek,
On Sun, Mar 7, 2021 at 12:26 PM Marek Behún marek.behun@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