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
