FWIW, I've got code elsewhere that detects lld-link, that looks like this:

Wrap up all the sets and logic for deciding what symbols to export into a class.

In D38937#898216, @ruiu wrote:

In D38937#898215, @mstorsjo wrote:

In D38937#898214, @ruiu wrote:

At this point I feel like we should define a function bool shouldExport(Defined *Sym) or something, so that we can move the code to that function.

Sounds like a good idea. How do you suggest to handle the exclude StringSets in that case - recreate them in each function invocation? Or have a static StringSet<> ExcludeSymbols in the global scope?

I don't know if this is a good idea, but since the number of strings you need to check is small, you may be able to just iterate over the list like this?

for (StringRef S : {"libgcc", "libgcc_s", ...})
  if (LibName == S)
    return false;

In D38937#898214, @ruiu wrote:

At this point I feel like we should define a function bool shouldExport(Defined *Sym) or something, so that we can move the code to that function.

Instead of trying to emulate the pthread rwlocks api with windows implementations, add a RWMutex class (with an interface similar to SmartRWMutex from LLVM) with inline implementations, which can either be no-ops (for no-threads configurations), implemented with SRW locks for windows or pthreads.

In D38704#897935, @majnemer wrote:

I don't think we should depend on LLVM for the locking stuff. This sort of infrastructure is in the same bucket as the demangler which we haven't really solved.

I *do* find it weird to do it this way though. I think you should have some mutex functions which include read/write unlock. This way you don't need the weird state.

Use __SIZEOF_POINTER__ instead of checking __LP64__ together with _WIN64. Changed _WIN32 into _WIN64 within the assembly sources for consistency/clarity. Removed one type definition ifdef by just using (u)intptr_t instead.

In D38704#892479, @zturner wrote:

I'm a little nervous about re-inventing a poor man's version of a reader writer lock. Can we not just copy LLVM's?

Seems ok to me, with whatever other architectures it's verified on as well.

Ping

This one can be abandoned now.

In D38513#896073, @smeenai wrote:

My hypothesis is that link might special-case zero-sized sections, but I have no evidence to back that up yet.

In D38821#895527, @compnerd wrote:

Don't you need a change to the intrinsics to actually map the builtin?

In D38513#895246, @smeenai wrote:

Could you elaborate on "the first object file in the static import library to be included is the function itself"? Is the function in question the linker-provided import thunk, or something else?

In D38821#895527, @compnerd wrote:

Don't you need a change to the intrinsics to actually map the builtin?

As further explanation/justification - libcxxabi and libunwind don't support SEH exceptions yet.

In D36111#895084, @mgrang wrote:

Sorry, I never got to complete this as I moved to other priorities. I do not think I have cycles to do this now. Please feel free to take over this patch :)

Constructing the exclude string sets directly instead of doing string transformations.

In D38760#895075, @ruiu wrote:

By the way, why does GNU ld export all symbols by default? Is it to emulate the ELF-ism on Windows?

In D38679#894668, @jroelofs wrote:

LGTM

Added more comments about this being mingw specific, changed to use a StringSet instead of a sorted vector.

@mgrang, did you ever get to completing this? I've got a need for this now (only __dmb so far), and if you don't have time, I can try to finish it.

In D38760#893870, @zturner wrote:

Isn't there a hard limit on the number of files that can be exported in COFF?

Print DATA in the output def for data symbols, adjusted the stdcall decoration for DllEntryPoint.

Changed the exclude list as suggested by Zachary (write all entries in fully decorated form and just substr the others), moved it to a separate function and using std::sort and std::binary_search instead of making a set of it. Added a comment and changed a condition into an early return, as suggested by Rui.

Are there any further comments on this, or can someone of those who commented on it before approve it?

Thanks for the review - one inline response to a comment, will do the other suggested changes tomorrow.

In D38128#892983, @jonpa wrote:

Thanks Martin - test case updated.

I checked the test that I had written (CodeGen/AArch64/win64_vararg.ll) and found one issue.

In D38680#892487, @compnerd wrote:

I think that the problem is that we are using the generic register name, but we need to use the target specific register name. On x86, EIP/ESP are swapped.

In D38704#892479, @zturner wrote:

I'm a little nervous about re-inventing a poor man's version of a reader writer lock. Can we not just copy LLVM's?

Changed the section name comparison to ==.

Added a fixme comment about the truncated section name, flipped the ifdef in the assembly source. Didn't implement findFunctionName.

Updated a comment together in sync with the updated code.

Updated the comment as requested.

@martell I think this patch can be discarded now. The CMake parts for mingw libs have been committed, and libunwind works for SjLj exceptions on mingw on x86, x86_64 and armv7 now (although only for static builds).

In D38513#887477, @ruiu wrote:

Import library files are tricky, and I don't fully understand how it works in the MSVC linker. It seems that because import libraries contain sections such as .idata$2, .idata$3, etc., they would be "naturally" processed and sorted in the MSVC linker, and as a result a correct output would be created. But I couldn't figure that out. So, lld implements a special logic for the import library.

Changed the if to a switch, added comments about what instructions are supposed to be generated, removed the superfluous conditional in the 32 bit codepath, expanded the test for x86_64 linux, renamed register variables as suggested (and renamed Base into BReg).

Simplified by making the enclosing function a member function to allow it using getGlobalWrapperKind instead.

Works fine with the version from r314632 (with a minor fixup in r314635).

Also get rid of some of the errors with -verify-machineinstrs.

Fixed the issues in unoptimized builds; it took some time to figure out that I couldn't use TargetOpcode::COPY to zero-extend a 32 bit register into 64 bit, but had to use TargetOpcode::SUBREG_TO_REG. Also now using more virtual registers for each intermediate value instead of reusing them - this seemed to produce more sensible annotated output from different register allocators (and doesn't matter when using optimizations properly). But if you prefer, I can reduce it down to just using as many virtual registers as before.