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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4UZIXGHYAVUGQEYWM2FVZFYOBPX6VFUH/
