Hi Florian, Hi Dave,
> /usr/bin/ld: build/intel64/libxsmm_main.o: relocation
R_X86_64_PC32 against symbol `libxsmm_crc32_u64' can not be used when making a shared
object; recompile with -fPIC
GCC emits calls to the function using:
call libxsmm_crc32_u64
This is a direct call, not through the PLT, and is allowed under the default x86-64
memory model for local (static) functions because all code fits into 2 GiB.
But annobin generates this:
.pushsection .text.libxsmm_crc32_u64
libxsmm_crc32_u64_end:
.popsection
.pushsection .gnu.build.attributes
.weak libxsmm_crc32_u64
.weak libxsmm_crc32_u64_end
.popsection
The .weak directive makes the symbol global, so it can be interposed from other modules,
and the direct call shown above is no longer permitted.
Nick, this looks like an annobin bug. This is really, really problematic from an ABI
perspective.
OK - so if I change annobin so that it creates its own function start symbol,
eg libxsmm_crc32_u64_start and then it references this symbol in the .weak
directive, (instead of libxsmm_crc32_u64), then everything should be OK right ?
Since the new symbol will be exclusive to annobin, it will not be used in any
function calls, and so no R_X86_64_PC32 relocs should be generated against it.
Cheers
Nick