[PATCH] D102453: [CMake][ELF] Add -fno-semantic-interposition for GCC and Clang>=13

Wed Jan 12 21:12:48 PST 2022

ljmf00 added a comment.

In D102453#3239347 <https://reviews.llvm.org/D102453#3239347>, @MaskRay wrote:

> Take this as an example:
>
>   ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol lto_module_is_object_file_for_target; recompile with -fPIC                              
>   >>> defined in tools/lto/CMakeFiles/LTO.dir/lto.cpp.o                                                                                                         
>   >>> referenced by lto.cpp:175 (/mnt/Workspace/Repos/collab/github/llvm/llvm-project/llvm/tools/lto/lto.cpp:175)                                               
>   >>>               tools/lto/CMakeFiles/LTO.dir/lto.cpp.o:(lto_module_is_object_file_for_target)                     
>
> You can delete `lto.cpp.o`, rerun `ninja` with -v to get the compiler command line. You can then remove unneeded options and then add -S to get the assembly.
> Check which instruction generates something like `R_X86_64_PC32` (you may need to compile with -c and compare .o output with .s)

I don't understand much about relocation linking issues and ELF interposition, although I produced some diffs that can be helpful here. I create two versions to compare with and without `-fno-semantic-interposition` and compare it with and without ASAN flags. To clarify, files with `.asan` means it was compiled with ASAN, `.noasan` the contrary, and files with `.nosem` means there is no `-fno-semantic-interposition` flag.

  --- lto.cpp.asan.S   2022-01-13 03:56:53.144475998 +0000
  +++ lto.cpp.asan.nosem.S        2022-01-13 04:19:12.177841103 +0000
  @@ -1399,7 +1399,7 @@
          movq    $1102416563, (%r15)             # imm = 0x41B58AB3
          leaq    .L___asan_gen_.1059(%rip), %rax
          movq    %rax, 8(%r15)
  -       leaq    lto_module_is_object_file_for_target(%rip), %rax
  +       movq    lto_module_is_object_file_for_target at GOTPCREL(%rip), %rax
          movq    %rax, 16(%r15)
          movq    %r15, %r14
          shrq    $3, %r14

  --- lto.cpp.noasan.S    2022-01-13 04:00:46.834481539 +0000
  +++ lto.cpp.noasan.nosem.S     2022-01-13 04:08:47.411159589 +0000
  @@ -352,7 +352,6 @@
          .p2align        4, 0x90
          .type   lto_get_version, at function
   lto_get_version:                        # @lto_get_version
  -.Llto_get_version$local:
   .Lfunc_begin2:
          .loc    2 162 0                         # llvm/tools/lto/lto.cpp:162:0
          .cfi_startproc

Interestingly, `objdump` diffs only procudes differences for ASAN binaries:

  --- /dev/fd/63  2022-01-13 04:42:05.491206955 +0000
  +++ /dev/fd/62  2022-01-13 04:42:05.494540289 +0000
  @@ -1,5 +1,5 @@

  -lto.cpp.asan.o:     file format elf64-x86-64
  +lto.cpp.asan.nosem.o:     file format elf64-x86-64

   Disassembly of section .text._ZN4llvm2cl3optIcLb0ENS0_6parserIcEEEC2IJA2_cNS0_4descENS0_15FormattingFlagsENS0_18NumOccurrencesFlagENS0_11initializerIcEEEEEDpRKT_:
  @@ -845,8 +845,8 @@
     79:  48 8d 05 00 00 00 00    lea    0x0(%rip),%rax        # 80 <lto_module_is_object_file_for_target+0x80>
                          7c: R_X86_64_PC32       .L___asan_gen_.1059-0x4
     80:  49 89 47 08             mov    %rax,0x8(%r15)
  -  84:  48 8d 05 00 00 00 00    lea    0x0(%rip),%rax        # 8b <lto_module_is_object_file_for_target+0x8b>
  -                       87: R_X86_64_PC32       lto_module_is_object_file_for_target-0x4
  +  84:  48 8b 05 00 00 00 00    mov    0x0(%rip),%rax        # 8b <lto_module_is_object_file_for_target+0x8b>
  +                       87: R_X86_64_REX_GOTPCRELX      lto_module_is_object_file_for_target-0x4
     8b:  49 89 47 10             mov    %rax,0x10(%r15)
     8f:  4d 89 fe                mov    %r15,%r14
     92:  49 c1 ee 03             shr    $0x3,%r14

See the generated binaries and assembly code here: https://cloudflare-ipfs.com/ipfs/bafybeiacqbizm2k4pwrcq6i3tzfl7xq3qp6z2kbso23rfapgjutdvkxqca/

I'm sorry for not being able to interpret that relocation flags, although, tell me if I can help with something else. I would appreciate helping solve it. In the meanwhile, I created a patch to disable this flag, at least on debug mode https://reviews.llvm.org/D117144 (since it is an "optimization"?).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102453/new/

https://reviews.llvm.org/D102453