-
Laurent Dufour authored
The commit 871da9a1 ("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 <ldufour@linux.vnet.ibm.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
0570dd81