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

[mstorsjo]

Summary

On Windows, if shouldAssumeDSOLocal returns false, it's either a dllimport reference, or a reference that we should treat as non-local and create a stub for.

Clean up AArch64Subtarget::ClassifyGlobalReference a little while touching the flag handling relating to dllimport.

This goes on top of D51452.

[rnk]

lgtm, thanks!

[vchuravy]

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

input.ll632 BDownload

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.

[mstorsjo]

In D51590#1634364, @vchuravy wrote:

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

input.ll632 BDownload

is taken from the LLVM testsuite and the result we are getting on LLVM 6.0.1

[...]

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

Thanks for reporting, and sorry for the breakage! I had indeed not thought about use with a different format than COFF.

Initially I thought I'd fix this by making the change in X86Subtarget.cpp preserve the earlier behaviour (returning MO_COFFSTUB even on windows/elf), but it seems to me that it doesn't really work (the COFFSTUB variables aren't created properly, as it needs a bit more support in the format specific code as well). And that solution also doesn't really work for arm/aarch64-windows-elf right now.

I think the best path forward is to skip the whole COFFSTUB business on windows on non-coff. I'll send a patch for that shortly.

llvm/trunk/lib/Target/AArch64/AArch64Subtarget.cpp

 unsigned char
 AArch64Subtarget::ClassifyGlobalReference(const GlobalValue *GV,
                                           const TargetMachine &TM) const {
   // MachO large model always goes via a GOT, simply to get a single 8-byte
   // absolute relocation on all global addresses.
   if (TM.getCodeModel() == CodeModel::Large && isTargetMachO())
     return AArch64II::MO_GOT;
 
-  unsigned Flags = AArch64II::MO_NO_FLAG;
+  if (!TM.shouldAssumeDSOLocal(*GV->getParent(), GV)) {
     if (GV->hasDLLImportStorageClass())
-    Flags = AArch64II::MO_DLLIMPORT;
-  else if (getTargetTriple().isWindowsGNUEnvironment() &&
-           !GV->isDSOLocal() && GV->isDeclarationForLinker() &&
-           isa<GlobalVariable>(GV))
-    Flags = AArch64II::MO_COFFSTUB | AArch64II::MO_GOT;
-
-  if (!TM.shouldAssumeDSOLocal(*GV->getParent(), GV))
-    return AArch64II::MO_GOT | Flags;
+      return AArch64II::MO_GOT | AArch64II::MO_DLLIMPORT;
+    if (getTargetTriple().isOSWindows())
+      return AArch64II::MO_GOT | AArch64II::MO_COFFSTUB;
+    return AArch64II::MO_GOT;
+  }
 
   // The small code model's direct accesses use ADRP, which cannot
   // necessarily produce the value 0 (if the code is above 4GB).
   // Same for the tiny code model, where we have a pc relative LDR.
   if ((useSmallAddressing() || TM.getCodeModel() == CodeModel::Tiny) &&
       GV->hasExternalWeakLinkage())
-    return AArch64II::MO_GOT | Flags;
+    return AArch64II::MO_GOT;
 
-  return Flags;
+  return AArch64II::MO_NO_FLAG;
 }
 
 unsigned char AArch64Subtarget::classifyGlobalFunctionReference(
     const GlobalValue *GV, const TargetMachine &TM) const {
   // MachO large model always goes via a GOT, because we don't have the
   // relocations available to do anything else..
   if (TM.getCodeModel() == CodeModel::Large && isTargetMachO() &&
       !GV->hasInternalLinkage())

llvm/trunk/lib/Target/ARM/ARMISelLowering.cpp

 SDValue ARMTargetLowering::LowerGlobalAddressWindows(SDValue Op,
                                                      SelectionDAG &DAG) const {
   assert(Subtarget->isTargetWindows() && "non-Windows COFF is not supported");
   assert(Subtarget->useMovt(DAG.getMachineFunction()) &&
          "Windows on ARM expects to use movw/movt");
   assert(!Subtarget->isROPI() && !Subtarget->isRWPI() &&
          "ROPI/RWPI not currently supported for Windows");
 
+  const TargetMachine &TM = getTargetMachine();
   const GlobalValue *GV = cast<GlobalAddressSDNode>(Op)->getGlobal();
   ARMII::TOF TargetFlags = ARMII::MO_NO_FLAG;
   if (GV->hasDLLImportStorageClass())
     TargetFlags = ARMII::MO_DLLIMPORT;
-  else if (Subtarget->getTargetTriple().isWindowsGNUEnvironment() &&
-           !GV->isDSOLocal() && GV->isDeclarationForLinker() &&
-           isa<GlobalVariable>(GV))
+  else if (!TM.shouldAssumeDSOLocal(*GV->getParent(), GV))
     TargetFlags = ARMII::MO_COFFSTUB;
   EVT PtrVT = getPointerTy(DAG.getDataLayout());
   SDValue Result;
   SDLoc DL(Op);
 
   ++NumMovwMovt;
 
   // FIXME: Once remat is capable of dealing with instructions with register

llvm/trunk/lib/Target/TargetMachine.cpp

bool TargetMachine::shouldAssumeDSOLocal(const Module &M,
 
   Reloc::Model RM = getRelocationModel();
   const Triple &TT = getTargetTriple();
 
   // DLLImport explicitly marks the GV as external.
   if (GV && GV->hasDLLImportStorageClass())
     return false;
 
+  // On MinGW, variables that haven't been declared with DLLImport may still
+  // end up automatically imported by the linker. To make this feasible,
+  // don't assume the variables to be DSO local unless we actually know
+  // that for sure. This only has to be done for variables; for functions
+  // the linker can insert thunks for calling functions from another DLL.
+  if (TT.isWindowsGNUEnvironment() && GV && GV->isDeclarationForLinker() &&
+      isa<GlobalVariable>(GV))
+    return false;
+
   // Every other GV is local on COFF.
   // Make an exception for windows OS in the triple: Some firmware builds use
   // *-win32-macho triples. This (accidentally?) produced windows relocations
   // without GOT tables in older clang versions; Keep this behaviour.
   if (TT.isOSBinFormatCOFF() || (TT.isOSWindows() && TT.isOSBinFormatMachO()))
     return true;
 
   // Most PIC code sequences that assume that a symbol is local cannot

llvm/trunk/lib/Target/X86/X86Subtarget.cpp

if (Optional<ConstantRange> CR = GV->getAbsoluteSymbolRange()) {
       // accept the range [0,128).
       if (CR->getUnsignedMax().ult(128))
         return X86II::MO_ABS8;
       else
         return X86II::MO_NO_FLAG;
     }
   }
 
-  // For MinGW, if a data reference isn't marked as DSO local or DLLImport,
-  // and it's a pure declaration without a definition, it might potentially
-  // be automatically imported from another DLL, thus route accesses via a stub.
-  if (isTargetWindowsGNU() && GV && !GV->isDSOLocal() &&
-      !GV->hasDLLImportStorageClass() && GV->isDeclarationForLinker() &&
-      isa<GlobalVariable>(GV))
-    return X86II::MO_COFFSTUB;
-
   if (TM.shouldAssumeDSOLocal(M, GV))
     return classifyLocalReference(GV);
 
-  if (isTargetCOFF())
+  if (isTargetCOFF()) {
+    if (GV->hasDLLImportStorageClass())
       return X86II::MO_DLLIMPORT;
+    return X86II::MO_COFFSTUB;
+  }
 
   if (is64Bit()) {
     // ELF supports a large, truly PIC code model with non-PC relative GOT
     // references. Other object file formats do not. Use the no-flag, 64-bit
     // reference for them.
     if (TM.getCodeModel() == CodeModel::Large)
       return isTargetELF() ? X86II::MO_GOT : X86II::MO_NO_FLAG;
     return X86II::MO_GOTPCREL;