[PATCH] D50917: [LLD] [COFF] Support MinGW automatic dllimport of data

Fri Aug 17 13:01:58 PDT 2018

mstorsjo created this revision.
mstorsjo added reviewers: ruiu, rnk, pcc, compnerd, smeenai.
Herald added a reviewer: javed.absar.
Herald added a subscriber: kristof.beyls.

GNU ld supports automatically importing data symbols from DLLs, when the references didn't have the appropriate dllimport attribute.  Since the PE/COFF format doesn't support that kind of relocations, fixing them up is handled by MinGW's CRT startup code. The linker creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code.

While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort.

Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see https://reviews.llvm.org/D43184 for some discussion on that.

The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address.

The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references.

With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this,
there are a few gotchas:

- References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64.
- For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset.
- Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows  Store/UWP apps, this function is forbidden.

These limitations will be addressed by a few later patches in lld and llvm.

Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D50917

Files:
  COFF/Chunks.cpp
  COFF/Chunks.h
  COFF/Driver.cpp
  COFF/SymbolTable.cpp
  COFF/SymbolTable.h
  COFF/Symbols.cpp
  COFF/Symbols.h
  COFF/Writer.cpp
  test/COFF/autoimport-arm-code.s
  test/COFF/autoimport-arm-data.s
  test/COFF/autoimport-arm64-code.s
  test/COFF/autoimport-arm64-data.s
  test/COFF/autoimport-list-ptrs.s
  test/COFF/autoimport-x86.s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D50917.161304.patch
Type: text/x-patch
Size: 21452 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180817/d57cee94/attachment.bin>