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

Rui Ueyama via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon May 7 14:37:29 PDT 2018


ruiu added inline comments.


================
Comment at: COFF/Driver.cpp:631
     Export E2;
+    if (E1.ExtName != E1.Name && StringRef(E1.Name).contains('.')) {
+      E2.Name = E1.ExtName;
----------------
mstorsjo wrote:
> 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.
By MS feature, I meant I'd make it clear that this is not MinGW-only feature. I'd think this is valuable information to add, as we've added a few MinGW-specific rules.


https://reviews.llvm.org/D46244





More information about the llvm-commits mailing list