ppc64: handle gcc memcpy optimisation
ppc64: handle gcc memcpy optimisation

The commit 871da9a11147 ("pie: Give VDSO symbol table local scope")
move the definition of the vdso_symbols from global to local variable
in vdso_fill_symtable(). This makes sense since this variable is only
used in this function. However this raises a build issue on powerPC,
where a memcpy undefined symbol is detected when doing the first
relocation phase of the parasite code:

parasite_blob: Error (pie/piegen/elf.c:258): Unexpected undefined
symbol:memcpy

This memcpy symbol is pulled by the C compiler generated code which
tries to optimize the stack initialization when entering
vdso_fill_symtable(). The optimization is done by copying the
initialized data to the stack using memcpy. But when building the
parasite code, the C library is not linked and there is no memcpy
symbol. However there is builtin_memcpy() which is doing the same.

Ideally, the builtin_memcpy should be named memcpy() to replace the C
library one, and it should only be built for the parasite/restorer
code. But the way CRIU is built, the same vdso-util.o file is used
twice for criu which is linked with the C library and by the
parasite/restorer code. Thus naming builtin_memcpy memcpy leads to
belongs on builtin_memcpy even when the C library is in the picture,
which is not the best option (assuming C library mem operation are
more efficient).

Among the memcpy symbol issue, this shows that same objects are used
both in CRIU and the parasite/restorer code. This should not be the
case since parasite/restorer are built in pie form and criu's object
not. The shared code should be built twice, once on pie form for the
parasite/restorer code, once *normally* for the criu binary.

Addressing the build issue implies more work than expected.
For the moment, this patch is defining a memcpy service when building
the parasite code to fix the build issue on ppc64.
Once the build issue is addressed, builtin_memcpy should be renamed
memcpy and only be used for parasite/restorer code, and this
definition removed.

Signed-off-by: Laurent Dufour <a59ffce977ae3d39bdc87f81ff88b229ad58db88@linux.vnet.ibm.com>
Signed-off-by: Pavel Emelyanov <c9a32589e048e044184536f7ac71ef92fe82df3e@parallels.com>

svloyso/criu,wtf42/criu,KKoukiou/criu-remote,AuthenticEshkinKot/criu,wtf42/criu,wtf42/criu,KKoukiou/criu-remote,ldu4/criu,fbocharov/criu,AuthenticEshkinKot/criu,fbocharov/criu,efiop/criu,svloyso/criu,AuthenticEshkinKot/criu,eabatalov/criu,wtf42/criu,fbocharov/criu,ldu4/criu,wtf42/criu,fbocharov/criu,tych0/criu,tych0/criu,wtf42/criu,ldu4/criu,AuthenticEshkinKot/criu,tych0/criu,AuthenticEshkinKot/criu,svloyso/criu,svloyso/criu,fbocharov/criu,ldu4/criu,eabatalov/criu,KKoukiou/criu-remote,fbocharov/criu,KKoukiou/criu-remote,efiop/criu,eabatalov/criu,ldu4/criu,tych0/criu,KKoukiou/criu-remote,eabatalov/criu,efiop/criu,KKoukiou/criu-remote,eabatalov/criu,efiop/criu,svloyso/criu,svloyso/criu,efiop/criu,ldu4/criu,tych0/criu,efiop/criu,eabatalov/criu,tych0/criu,AuthenticEshkinKot/criu