[llvm] [lld] [LTO] [LLD] Don't alias the __imp_func and func symbol resolutions (PR #71376)

Martin Storsjö via llvm-commits llvm-commits at lists.llvm.org
Sat Nov 18 06:08:48 PST 2023


mstorsjo wrote:

> > [LTO] [LLD] Don't alias the __imp_func and func symbol resolutions
> 
> The patch changes the behavior of data symbols as well. Consider adding a test to check its current behavior (I think it's fine whether it makes sense or not; the test just serves as a change detector). I haven't thought hard about data symbols.

The mechanism work exactly the same for data symbols; if you have a dllimport reference to a data symbol in one object file, that symbol can be provided either with an explicit `__imp_sym` pointer in another object file (works in all linkers, mostly used in the mingw ecosystem), or if another object file just provides `sym`, then LLD and MS link.exe will synthesize such a pointer and print a warning (`locally defined symbol imported ... [LNK4217]`) - this is only relied upon in the MSVC ecosystem as GNU ld doesn't do that. The functional change in LLD only affects the latter case.

(As a side note; the reverse, where a data symbol is referenced without a dllimport attribute, but the data symbol only is available in dllimport form from another DLL, is the tricky case. In MSVC environments, this is not supported, while in mingw environments, it is supported via the "autoimport" mechanism, which in worst case requires runtime pseudo relocations which are fixed up at startup by the mingw runtime.)

https://github.com/llvm/llvm-project/pull/71376


More information about the llvm-commits mailing list