[PATCH] D46244: [LLD] [COFF] Allow specifying export forwarding in a def file

Martin Storsjö via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat May 5 12:54:05 PDT 2018


mstorsjo added inline comments.


================
Comment at: COFF/Driver.cpp:631
     Export E2;
+    if (E1.ExtName != E1.Name && StringRef(E1.Name).contains('.')) {
+      E2.Name = E1.ExtName;
----------------
ruiu wrote:
> mstorsjo wrote:
> > ruiu wrote:
> > > Can you add a comment?
> > Sure - I can add one like this:
> > 
> > In simple cases, only Name is set. Renamed exports are parsed and set as "ExtName = Name". If Name has the form "OtherDll.Func", it shouldn't be a normal exported function but a forward to another DLL instead.
> > 
> > 
> Sounds good! I'd also mention that this is a MS linker feature.
It's not only a MS linker feature, GNU ld.bfd also supports the same, so I didn't add this comment.

I started poking all this when I wanted to fix the misconception as I'm fixing in D46245, which all boiled down to the comment "// GNU dlltool accepts both = and ==." The thing is that GNU tools do support both = and ==, but they're two completely different things, while the = case is the exact same as in link.exe. Due to this misunderstanding, we've been overloading the same concept with different behaviours between MinGW and MSVC cases, even though it's actually much less messy.


https://reviews.llvm.org/D46244





More information about the llvm-commits mailing list