[PATCH] D51590: [MinGW] Move code for indicating "potentially not DSO local" into shouldAssumeDSOLocal. NFCI.

Sun Aug 18 03:30:14 PDT 2019

vchuravy added a comment.
Herald added a project: LLVM.

This broke Julia downstream (https://github.com/JuliaLang/julia/pull/32712#issuecomment-521206577). In Julia we emit JIT'ed code on MINGW as ELF+Static relocation model (https://github.com/JuliaLang/julia/blob/be3b04b29654a463b4dc899a228b5f53e862cdde/src/codegen.cpp#L7653-L7669), due us having issues with COFF support in RuntimeDyld.

The attached file F9818390: input.ll <https://reviews.llvm.org/F9818390> is taken from the LLVM testsuite and the result we are getting on LLVM 6.0.1

  llc -mtriple=i686-w64-mingw32-none-elf --filetype=obj -o v6.0.1/input.o input.ll
  objdump -r v6.0.1/input.o

  v6.0.1/input.o:     file format elf32-i386

  RELOCATION RECORDS FOR [.text]:
  OFFSET   TYPE              VALUE
  00000004 R_386_32          __stack_chk_guard
  00000014 R_386_PC32        other
  00000023 R_386_32          __stack_chk_guard
  00000030 R_386_PC32        __stack_chk_fail

  RELOCATION RECORDS FOR [.eh_frame]:
  OFFSET   TYPE              VALUE
  00000020 R_386_PC32        .text

If I compile it with relocation-model=pic

  llc -mtriple=i686-w64-mingw32-none-elf --relocation-model=pic --filetype=obj -o v6.0.1/input.o input.ll
  objdump -r v6.0.1/input.o

  v6.0.1/input.o:     file format elf32-i386

  RELOCATION RECORDS FOR [.text]:
  OFFSET   TYPE              VALUE
  0000000d R_386_GOTPC       _GLOBAL_OFFSET_TABLE_
  00000013 R_386_GOT32       __stack_chk_guard
  00000025 R_386_PC32        other
  0000003f R_386_PLT32       __stack_chk_fail

  RELOCATION RECORDS FOR [.eh_frame]:
  OFFSET   TYPE              VALUE
  00000020 R_386_PC32        .text

RuntimeDyld doesn't support R_386_GOT32:

  llvm-rtdyld -triple=i686-w64-mingw32-none-elf --dummy-extern other=1 --dummy-extern __stack_chk_fail=2 --dummy-extern __stack_chk_guard=3 --dummy-extern _GLOBAL_OFFSET_TABLE_=4 -verify v6.0.1/input.o
  Relocation type not implemented yet!
  UNREACHABLE executed at /workspace/srcdir/llvm-6.0.1.src/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:340!
  #0 0x00007f685dfa3b0a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/vchuravy/projects/reproduce-win32-32712/v6.0.1/tools/../lib/libLLVM-6.0.so+0x706b0a)
  #1 0x00007f685dfa16ae llvm::sys::RunSignalHandlers() (/home/vchuravy/projects/reproduce-win32-32712/v6.0.1/tools/../lib/libLLVM-6.0.so+0x7046ae)
  #2 0x00007f685dfa192a SignalHandler(int) (/home/vchuravy/projects/reproduce-win32-32712/v6.0.1/tools/../lib/libLLVM-6.0.so+0x70492a)
  #3 0x00007f685d840d00 __restore_rt (/usr/lib/libpthread.so.0+0x13d00)
  #4 0x00007f685d35c755 __GI_raise (/usr/lib/libc.so.6+0x3a755)
  #5 0x00007f685d347851 __GI_abort (/usr/lib/libc.so.6+0x25851)
  #6 0x00007f685df2511a (/home/vchuravy/projects/reproduce-win32-32712/v6.0.1/tools/../lib/libLLVM-6.0.so+0x68811a)
  #7 0x00007f685f2c78cd llvm::RuntimeDyldELF::resolveX86Relocation(llvm::SectionEntry const&, unsigned long, unsigned int, unsigned int, int) (/home/vchuravy/projects/reproduce-win32-32712/v6.0.1/tools/../lib/libLLVM-6.0.so+0x1a2a8cd)
  #8 0x00007f685f2c8c21 llvm::RuntimeDyldELF::resolveRelocation(llvm::RelocationEntry const&, unsigned long) (/home/vchuravy/projects/reproduce-win32-32712/v6.0.1/tools/../lib/libLLVM-6.0.so+0x1a2bc21)
  #9 0x00007f685f2afa1b llvm::RuntimeDyldImpl::resolveRelocationList(llvm::SmallVector<llvm::RelocationEntry, 64u> const&, unsigned long) (/home/vchuravy/projects/reproduce-win32-32712/v6.0.1/tools/../lib/libLLVM-6.0.so+0x1a12a1b)
  #10 0x00007f685f2b5152 llvm::RuntimeDyldImpl::resolveExternalSymbols() (/home/vchuravy/projects/reproduce-win32-32712/v6.0.1/tools/../lib/libLLVM-6.0.so+0x1a18152)
  #11 0x00007f685f2b5d4e llvm::RuntimeDyldImpl::resolveRelocations() (/home/vchuravy/projects/reproduce-win32-32712/v6.0.1/tools/../lib/libLLVM-6.0.so+0x1a18d4e)
  #12 0x000000000040d0ee linkAndVerify() (v6.0.1//tools/llvm-rtdyld+0x40d0ee)
  #13 0x00000000004049ef main (v6.0.1//tools/llvm-rtdyld+0x4049ef)
  #14 0x00007f685d348ee3 __libc_start_main (/usr/lib/libc.so.6+0x26ee3)
  #15 0x000000000040608e _start /workspace/srcdir/glibc-2.12.2/csu/../sysdeps/x86_64/elf/start.S:116:0
  Stack dump:
  0.	Program arguments: v6.0.1//tools/llvm-rtdyld -triple=i686-w64-mingw32-none-elf --dummy-extern other=1 --dummy-extern __stack_chk_fail=2 --dummy-extern __stack_chk_guard=3 --dummy-extern _GLOBAL_OFFSET_TABLE_=4 -verify v6.0.1/input.o

So far so good. On LLVM 8.0.1+ (I also tested on LLVM 9.0.1) the input.ll causes a segmentation fault further downstream.

  llc -mtriple=i686-w64-mingw32-none-elf --filetype=obj -o v8.0.1/input.o input.ll
  Stack dump:
  0.	Program arguments: v8.0.1//tools/llc -mtriple=i686-w64-mingw32-none-elf --filetype=obj -o v8.0.1/input.o input.ll
  1.	Running pass 'Function Pass Manager' on module 'input.ll'.
  2.	Running pass 'Machine Common Subexpression Elimination' on function '@func'
   #0 0x00007fb8f75715fa llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/vchuravy/projects/reproduce-win32-32712/v8.0.1/tools/../lib/libLLVM-8.so+0x77b5fa)
   #1 0x00007fb8f756f474 llvm::sys::RunSignalHandlers() (/home/vchuravy/projects/reproduce-win32-32712/v8.0.1/tools/../lib/libLLVM-8.so+0x779474)
   #2 0x00007fb8f756f5d5 SignalHandler(int) (/home/vchuravy/projects/reproduce-win32-32712/v8.0.1/tools/../lib/libLLVM-8.so+0x7795d5)
   #3 0x00007fb8f6d99d00 __restore_rt (/usr/lib/libpthread.so.0+0x13d00)
   #4 0x00007fb8f7897544 (anonymous namespace)::MachineCSE::ProcessBlock(llvm::MachineBasicBlock*) (/home/vchuravy/projects/reproduce-win32-32712/v8.0.1/tools/../lib/libLLVM-8.so+0xaa1544)
   #5 0x00007fb8f78999f0 (anonymous namespace)::MachineCSE::PerformCSE(llvm::DomTreeNodeBase<llvm::MachineBasicBlock>*) (/home/vchuravy/projects/reproduce-win32-32712/v8.0.1/tools/../lib/libLLVM-8.so+0xaa39f0)
   #6 0x00007fb8f78bacf6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.41) (/home/vchuravy/projects/reproduce-win32-32712/v8.0.1/tools/../lib/libLLVM-8.so+0xac4cf6)
   #7 0x00007fb8f7690e89 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/vchuravy/projects/reproduce-win32-32712/v8.0.1/tools/../lib/libLLVM-8.so+0x89ae89)
   #8 0x00007fb8f7690f29 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/vchuravy/projects/reproduce-win32-32712/v8.0.1/tools/../lib/libLLVM-8.so+0x89af29)
   #9 0x00007fb8f7690328 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/vchuravy/projects/reproduce-win32-32712/v8.0.1/tools/../lib/libLLVM-8.so+0x89a328)
  #10 0x00000000004192b3 compileModule(char**, llvm::LLVMContext&) (v8.0.1//tools/llc+0x4192b3)
  #11 0x000000000040ba65 main (v8.0.1//tools/llc+0x40ba65)
  #12 0x00007fb8f68a1ee3 __libc_start_main (/usr/lib/libc.so.6+0x26ee3)
  #13 0x000000000040bbde _start /workspace/srcdir/glibc-2.12.2/csu/../sysdeps/x86_64/elf/start.S:116:0

This segmentation fault may be unrelated to the problem at hand, but tracing with GDB showed that the relocation type selected (despite relocation-model static) is R_386_GOT32 as I observed in the initial debugging https://github.com/JuliaLang/julia/pull/32712#issuecomment-521206577

Reverting this revision locally caused the segmentation fault to go away and to produce the same relocations as LLVM 6.0.1.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D51590