[PATCH] D50917: [LLD] [COFF] Support MinGW automatic dllimport of data
Martin Storsjö via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 20 12:28:37 PDT 2018
mstorsjo added a comment.
In https://reviews.llvm.org/D50917#1206111, @rnk wrote:
> Sigh. ELF supports too much and lets people do too much, and then we have to go reimplement that functionality badly for other object file formats that tried to be simple.
>
> Anyway, we should do something. I understand that for many developers, Windows is a corner case platform and they are going to spend approximately zero effort porting their code to it, so this feature is valuable to them.
Indeed... While using this feature to handle libraries public APIs with data symbols is one thing, the fact that it more or less is required for the itanium C++ ABI tipped the scales for me about implementing it (instead of the clang-contained kludge I tried before).
> Will subsequent LLVM patches make the compiler use more general code sequences for global variable access, like an IAT load? That would address the list of architectural limitations you outlined.
Yes, exactly. I've got patches that make every global variable access (except those where we do see a definition, making it sure that it really is DSO local) go via a variable stub. And once you have such a stub, you can even replace accesses to it with an access to `__imp_<sym>` in the linker, avoiding most runtime relocations (except for cases where the pointer is used in initialized data, like in the C++ cases). And finally we can make all sections that still contain runtime relocations writable, avoiding any need for VirtualProtect at runtime.
================
Comment at: COFF/Chunks.h:161
+ void getRuntimePseudoRelocs(std::vector<RuntimePseudoReloc> *Res);
+
----------------
rnk wrote:
> This can be a reference to indicate that it is required and not nullable.
Ok, will change.
================
Comment at: test/COFF/autoimport-arm-code.s:10
+
+# CHECK: error: unable to automatically import from variable with relocation type 0x11
+
----------------
rnk wrote:
> Do we have a table to print relocations symbolically?
Yes, there is something in lib/Object, I'll try to make use of it.
Repository:
rLLD LLVM Linker
https://reviews.llvm.org/D50917
More information about the llvm-commits
mailing list