[RFC] Build LLVM-C.dll on MSVC that exports only the C API

[Wallbraker]

Summary

Hello!

This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more.

The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin.

Improvements that I need help with, to follow up this review.

• Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script.
• Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported.
• Bundle the LLVM-C.dll with the windows installer.

Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL.

Any comments, thoughts or help is greatly appreciated.

Cheers, Jakob.

Patch by: Wallbraker (Jakob Bornecrantz)

[smeenai]

(adding some Windows and cmake people)

[Wallbraker]

Ping?

[beanz]

I don't think this should be added as a new tool. We support generating LLVM-C.dylib on Darwin via the tools/llvm-shlib tool. It would be better if this were added there instead of completely separate.

[Wallbraker]

In D35077#813499, @beanz wrote:

I don't think this should be added as a new tool. We support generating LLVM-C.dylib on Darwin via the tools/llvm-shlib tool. It would be better if this were added there instead of completely separate.

Thank you for your comment, I respun this patch so that it does not add a new tool but reuse the llvm-shlib tool.

It becomes a bit more ugly then because:

1. The LLVM-C.dylib on Darwin is a re-export library that holds no code it just points to LLVM.dylib but only the LLVM C API functions are exported.
2. I'm pretty sure we do not want to ship a LLVM.dll exporting all of the C++ functions (I could be wrong here and we want to) so we should not build it on Windows.
3. So we only build LLVM-C.dll without using a re-export library (also don't know how to do that on Windows).
4. The llvm-shlib directory is only built if LLVM.dylib is built, which we do not want to do on Windows, see 2. So had to jump through some hoops to get it to enter it.

Both patches are in my llvm repo on github https://github.com/Wallbraker/llvm

Thanks, Jakob.

[compnerd]

Forwarders on Windows are roughly the equivalent to a re-export library. They aren't exactly the same thing as you need to list all the interfaces instead of saying all interfaces from this library.

[rnk]

I never found time to look at this, removing myself to better reflect reality. I guess my stance is that we should start picking and choosing C++ APIs to expose from an LLVM DSO that we ship on all platforms. This isn't really a step towards or away from that goal, so I don't have many feelings one way or another. If the owners of the existing llvm-shlib logic are OK with this CMake complexity and it's useful to someone, I'm OK with it.

[beanz]

LGTM.

[Wallbraker]

Thanks for the review, I do not have commit access so somebody needs to commit this for me.

Cheers. Jakob.

[Memnarch]

In D35077#838535, @Wallbraker wrote:

Thanks for the review, I do not have commit access so somebody needs to commit this for me.

Cheers. Jakob.

Just tried it and it worked like a charm, just one little issue(when building from VisualStudio):
CMAKE_BINARY_DIR will not include Debug/Release Subdirectory and therefore the pythonscript will complain about missing files. I just added my desired config to the path in the script and it worked.
The question is, is this fixable? Or did i do something wrong on my end?

EDIT: To avoid confusion, i do not have commit-access either

[chapuni]

Please honor CMAKE_CFG_INTDIR. See also LLVM_*_OUTPUT_INTDIR.

[Wallbraker]

I have updated the commit to use for locating the libs CMAKE_CFG_INTDIR and should fix the issue @Memnarch saw. I only have build tools installed so I don't know if I can test it under a Visual Studio like environment.

Cheers, Jakob.

[Memnarch]

In D35077#863339, @Wallbraker wrote:

I have updated the commit to use for locating the libs CMAKE_CFG_INTDIR and should fix the issue @Memnarch saw. I only have build tools installed so I don't know if I can test it under a Visual Studio like environment.

Cheers, Jakob.

Can you check your diff? Expected changes in "tools/llvm-shlib/CMakeLists.txt" only but all files are modified with other changes(compare the new diff with the previous one)

[Wallbraker]

In D35077#863378, @Memnarch wrote:

In D35077#863339, @Wallbraker wrote:

I have updated the commit to use for locating the libs CMAKE_CFG_INTDIR and should fix the issue @Memnarch saw. I only have build tools installed so I don't know if I can test it under a Visual Studio like environment.

Cheers, Jakob.

Can you check your diff? Expected changes in "tools/llvm-shlib/CMakeLists.txt" only but all files are modified with other changes(compare the new diff with the previous one)

Those are not my changes, I think they are a artifact from me uploading a diff manually and the fact that the code has changed from the last time I uploaded the diff (The LLVM docs tells me to upload the diff with full context). There are two lines that show up in a slightly brighter green, those are the only changes I have made.

[Memnarch]

In D35077#863412, @Wallbraker wrote:

In D35077#863378, @Memnarch wrote:

In D35077#863339, @Wallbraker wrote:

I have updated the commit to use for locating the libs CMAKE_CFG_INTDIR and should fix the issue @Memnarch saw. I only have build tools installed so I don't know if I can test it under a Visual Studio like environment.

Cheers, Jakob.

Can you check your diff? Expected changes in "tools/llvm-shlib/CMakeLists.txt" only but all files are modified with other changes(compare the new diff with the previous one)

Those are not my changes, I think they are a artifact from me uploading a diff manually and the fact that the code has changed from the last time I uploaded the diff (The LLVM docs tells me to upload the diff with full context). There are two lines that show up in a slightly brighter green, those are the only changes I have made.

i suspected that. But for the purpose of this review, you should remove these changes

[Wallbraker]

This should not have any other changes, I think. Problem is I do not know which revision the old one was based on.

[Memnarch]

That looks much better. When in doubt, you can always download the revisions from the most recent(or any other diff) to make those changes based on those.

[Wallbraker]

In D35077#863504, @Memnarch wrote:

That looks much better. When in doubt, you can always download the revisions from the most recent(or any other diff) to make those changes based on those.

Excellent, okay thanks. Have you had a chance to try this on Visual Studio, I'm interested in knowing if this fixes your issue?

[Memnarch]

In D35077#863537, @Wallbraker wrote:

In D35077#863504, @Memnarch wrote:

That looks much better. When in doubt, you can always download the revisions from the most recent(or any other diff) to make those changes based on those.

Excellent, okay thanks. Have you had a chance to try this on Visual Studio, I'm interested in knowing if this fixes your issue?

Worked

[Wallbraker]

Ping?

I don't have commit access so I need somebody to commit this for me, it has been like a month since I got the first LGTM on this review.

[Wallbraker]

Ping?

[Memnarch]

Maybe this is a candidate for http://llvmweekly.org/reviewcorner
Submit it and it'll hopefully show up on the next weekly!

[Memnarch]

In D35077#878147, @Wallbraker wrote:

Ping?

did you submit it to the reviewcorner?

[Wallbraker]

No sorry, I moved and started a new job. And don't have access to the windows machine for a while.

I can update the patch to master (which is a requirement for reviewcorner), but not test it.

Cheers, Jakob.

[Wallbraker]

This is a NFC update to the patch, bringing it up to master. As I wrote above I can't test it, but should work just fine.

If anybody can test it I can ask for inclusion in the next reviewcorner.

Cheers, Jakob.

[Memnarch]

In D35077#902225, @Wallbraker wrote:

This is a NFC update to the patch, bringing it up to master. As I wrote above I can't test it, but should work just fine.

If anybody can test it I can ask for inclusion in the next reviewcorner.

Cheers, Jakob.

Ok since nobody else responded while i was absent, i'll test it during the next days. Have some time on Thurday, so we can get this to the ReviewCorner ASAP. Just in case it got incompatible with HEAD, can you check in the meantime?

[Memnarch]

@compnerd @beanz @Wallbraker
Tested it on Master (CommitID: 0ba1cd85f0f79ad7f3831690a243ec7d9421bab7)
Seemed to run fine.

[Wallbraker]

Thanks for testing again @Memnarch, I'm going to update this changeset soon and then try to get it included in LLVM Weekly.

Cheers, Jakob.

[Wallbraker]

Updated the diff to master, haven't build tested yet.

[Wallbraker]

Added people who seems to be doing stuff with cmake on windows.

[Wallbraker]

Another update of the commit for llvm master.

[bhelyer]

I work with Jakob on the afore mentioned self hosting language frontend. Would like to see this get in, what else is needed? I just built the version that Jakob recently updated, and it produces a LLVM-C.dll and lib file with what looks like the right functions (when looked at with a dependency walker); not sure how best to test it beyond that. Let me know what needs to be done and I'll try my best to do it.

[bhelyer]

Upon further testing, I can verify that the generated DLL appears to work.

[smeenai]

Sorry this has been sitting for so long. I have some questions, and I'll also try to play around with this locally because I don't fully understand some parts.

CMakeLists.txt

554

Comment is unnecessary as-is. Why does this default to on though, given that the corresponding Darwin option defaults to off?

559

CMake has the same precedence for AND and OR (unlike most programming languages), so I always prefer adding parentheses to make the precedence clear. (That would also remove the need for reordering the parts of the OR here.)

tools/CMakeLists.txt

21

How does this ensure we'll always build on Windows?

tools/llvm-shlib/CMakeLists.txt

129

This is used for user label prefix purposes, so it's better to just pass the user label prefix (or whether there is one) to the script. In particular, arm and arm64 also don't have a user label prefix; it's only x86 that does.

You can either preprocess a simple program for the target and see what the __USER_LABEL_PREFIX__ macro expands to, or you can assume that x86 means the user label prefix is _ and any other architecture means no user label prefix. I'd be fine with either one.

tools/llvm-shlib/gen-msvc-exports.py

65

Can we use one of llvm-nm, llvm-objdump, or llvm-readobj instead? It would allow building this when cross-compiling and would remove the dependency on the VS command prompt (although you'd probably want to take the path to the LLVM program as an argument).

[bhelyer]

CMakeLists.txt

554

The idea is that we would like the DLL included in the windows published on llvm.org, if that's out of scope for this changeset, we can switch it to OFF and take that up elsewhere.

Either way, I'll nix the comment.

559

Roger. I'm still learning this cmake stuff, and I'll have to play around with cmake -P to make sure I've got the way everything binds correct.

tools/CMakeLists.txt

21

As LLVM_BUILD_LLVM_C_DYLIB is set to On on windows by default, this will always evaluate false on windows.

tools/llvm-shlib/CMakeLists.txt

129

To be honest, this one is a bit out of depth for me as yet, but I'll be sure to poke Jakob about it.

tools/llvm-shlib/gen-msvc-exports.py

65

I'll have to test the results to make sure it actually works and then wire it up, but all the tools look like they can output the information we need from the .lib files, so this shouldn't be an issue.

[smeenai]

CMakeLists.txt

554

I think it makes sense to have it default to off and then we could request the Windows packaging to turn this option on. @hans does that sound okay?

tools/CMakeLists.txt

21

It's on by default (pending our discussion above), but someone could override it themselves and then the comment wouldn't hold, right?

tools/llvm-shlib/gen-msvc-exports.py

65

Cool. I think llvm-nm -g should be equivalent to dumpbin /linkermember:1.

[Wallbraker]

Updated with @bhelyer changes and updated to latest master.

[Wallbraker]

That should be all of the comments done.

[Wallbraker]

Can this please please please be pushed ASAP so it can go in to the 7.0 release?

[xbolva00]

In D35077#1190698, @Wallbraker wrote:

Can this please please please be pushed ASAP so it can go in to the 7.0 release?

ask @hans if he can merge it to 7.0 branch :)

[hans]

In D35077#1190945, @xbolva00 wrote:

In D35077#1190698, @Wallbraker wrote:

Can this please please please be pushed ASAP so it can go in to the 7.0 release?

ask @hans if he can merge it to 7.0 branch :)

I'd prefer not to merge it. Since this is a new feature that's been in the pipe for over a year, I don't think we should rush it in now. It would be better to let it land safely on trunk, get any kinks worked out and then have it be part of the next release.

We should also check whether this will become part of the installer automatically, you can see how its built in utils/release/build_llvm_package.bat, or if that needs some update.

[Wallbraker]

In D35077#1191123, @hans wrote:

In D35077#1190945, @xbolva00 wrote:

In D35077#1190698, @Wallbraker wrote:

Can this please please please be pushed ASAP so it can go in to the 7.0 release?

ask @hans if he can merge it to 7.0 branch :)

I'd prefer not to merge it. Since this is a new feature that's been in the pipe for over a year, I don't think we should rush it in now. It would be better to let it land safely on trunk, get any kinks worked out and then have it be part of the next release.

We should also check whether this will become part of the installer automatically, you can see how its built in utils/release/build_llvm_package.bat, or if that needs some update.

Ok that make sense!

@hans Right now it is not built by default, but I would be very happy to change that as that will give the change much more coverage. So either we would need to change build_llvm_package.bat to include that option or change the default.

Also you can break bat lines up similar to bash ones with ^ which might make the cmake command a bit more readable.

CMakeLists.txt

 # You can configure which libraries from LLVM you want to include in the
 # shared library by setting LLVM_DYLIB_COMPONENTS to a semi-colon delimited
 # list of LLVM components. All component names handled by llvm-config are valid.
 if(NOT DEFINED LLVM_DYLIB_COMPONENTS)
   set(LLVM_DYLIB_COMPONENTS "all" CACHE STRING
     "Semicolon-separated list of components to include in libLLVM, or \"all\".")
 endif()
 option(LLVM_LINK_LLVM_DYLIB "Link tools against the libllvm dynamic library" OFF)
-option(LLVM_BUILD_LLVM_C_DYLIB "Build libllvm-c re-export library (Darwin Only)" OFF)
+if(MSVC)
+  option(LLVM_BUILD_LLVM_C_DYLIB "Build LLVM-C.dll (Windows only)" OFF)
+else()
+  option(LLVM_BUILD_LLVM_C_DYLIB "Build libllvm-c re-export library (Darwin only)" OFF)
+endif()
 set(LLVM_BUILD_LLVM_DYLIB_default OFF)
-if(LLVM_LINK_LLVM_DYLIB OR LLVM_BUILD_LLVM_C_DYLIB)
+if(LLVM_LINK_LLVM_DYLIB OR (LLVM_BUILD_LLVM_C_DYLIB AND NOT MSVC))
   set(LLVM_BUILD_LLVM_DYLIB_default ON)
 endif()
 option(LLVM_BUILD_LLVM_DYLIB "Build libllvm dynamic library" ${LLVM_BUILD_LLVM_DYLIB_default})
 
 option(LLVM_OPTIMIZED_TABLEGEN "Force TableGen to be built with optimization" OFF)
 if(CMAKE_CROSSCOMPILING OR (LLVM_OPTIMIZED_TABLEGEN AND (LLVM_ENABLE_ASSERTIONS OR CMAKE_CONFIGURATION_TYPES)))
   set(LLVM_USE_HOST_TOOLS ON)
 endif()

tools/CMakeLists.txt

 # Build polly before the tools: the tools link against polly when
 # LINK_POLLY_INTO_TOOLS is set.
 if(WITH_POLLY)
   add_llvm_external_project(polly)
 else()
   set(LLVM_TOOL_POLLY_BUILD Off)
 endif()
 
-if(NOT LLVM_BUILD_LLVM_DYLIB )
+if(NOT LLVM_BUILD_LLVM_DYLIB AND NOT LLVM_BUILD_LLVM_C_DYLIB)
   set(LLVM_TOOL_LLVM_SHLIB_BUILD Off)
 endif()
 
 if(NOT LLVM_USE_INTEL_JITEVENTS )
   set(LLVM_TOOL_LLVM_JITLISTENER_BUILD Off)
 endif()
 
 if(CYGWIN OR NOT LLVM_ENABLE_PIC)
   set(LLVM_TOOL_LTO_BUILD Off)

tools/llvm-shlib/CMakeLists.txt

 # This tool creates a shared library from the LLVM libraries. Generating this
 # library is enabled by setting LLVM_BUILD_LLVM_DYLIB=yes on the CMake
 # commandline. By default the shared library only exports the LLVM C API.
 
 set(SOURCES
   libllvm.cpp
   )
 
-llvm_map_components_to_libnames(LIB_NAMES ${LLVM_DYLIB_COMPONENTS})
-
 if(LLVM_LINK_LLVM_DYLIB AND LLVM_DYLIB_EXPORTED_SYMBOL_FILE)
   message(WARNING "Using LLVM_LINK_LLVM_DYLIB with LLVM_DYLIB_EXPORTED_SYMBOL_FILE may not work. Use at your own risk.")
 endif()
 
+if(LLVM_BUILD_LLVM_DYLIB)
+  if(MSVC)
+    message(FATAL_ERROR "Generating libLLVM is not supported on MSVC")
+  endif()
+
+  llvm_map_components_to_libnames(LIB_NAMES ${LLVM_DYLIB_COMPONENTS})
+
   # libLLVM.so should not have any dependencies on any other LLVM
   # shared libraries. When using the "all" pseudo-component,
   # LLVM_AVAILABLE_LIBS is added to the dependencies, which may
   # contain shared libraries (e.g. libLTO).
   #
   # Also exclude libLLVMTableGen for the following reasons:
   #  - it is only used by internal *-tblgen utilities;
   #  - it pollutes the global options space.
   foreach(lib ${LIB_NAMES})
     get_target_property(t ${lib} TYPE)
     if("${lib}" STREQUAL "LLVMTableGen")
     elseif("x${t}" STREQUAL "xSTATIC_LIBRARY")
       list(APPEND FILTERED_LIB_NAMES ${lib})
     endif()
   endforeach()
   set(LIB_NAMES ${FILTERED_LIB_NAMES})
 
   if(LLVM_DYLIB_EXPORTED_SYMBOL_FILE)
     set(LLVM_EXPORTED_SYMBOL_FILE ${LLVM_DYLIB_EXPORTED_SYMBOL_FILE})
     add_custom_target(libLLVMExports DEPENDS ${LLVM_EXPORTED_SYMBOL_FILE})
   endif()
 
   add_llvm_library(LLVM SHARED DISABLE_LLVM_LINK_LLVM_DYLIB SONAME ${SOURCES})
 
   list(REMOVE_DUPLICATES LIB_NAMES)
   if(("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux") OR (MINGW) OR (HAIKU)
      OR ("${CMAKE_SYSTEM_NAME}" STREQUAL "FreeBSD")
      OR ("${CMAKE_SYSTEM_NAME}" STREQUAL "OpenBSD")
      OR ("${CMAKE_SYSTEM_NAME}" STREQUAL "Fuchsia")
      OR ("${CMAKE_SYSTEM_NAME}" STREQUAL "DragonFly")
      OR ("${CMAKE_SYSTEM_NAME}" STREQUAL "SunOS")) # FIXME: It should be "GNU ld for elf"
     configure_file(
     ${CMAKE_CURRENT_SOURCE_DIR}/simple_version_script.map.in
     ${LLVM_LIBRARY_DIR}/tools/llvm-shlib/simple_version_script.map)
 
     # GNU ld doesn't resolve symbols in the version script.
     set(LIB_NAMES -Wl,--whole-archive ${LIB_NAMES} -Wl,--no-whole-archive)
     if (NOT LLVM_LINKER_IS_SOLARISLD)
       # Solaris ld does not accept global: *; so there is no way to version *all* global symbols
       set(LIB_NAMES -Wl,--version-script,${LLVM_LIBRARY_DIR}/tools/llvm-shlib/simple_version_script.map ${LIB_NAMES})
     endif()
   elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
     set(LIB_NAMES -Wl,-all_load ${LIB_NAMES})
   endif()
 
   target_link_libraries(LLVM PRIVATE ${LIB_NAMES})
 
   if (APPLE)
     set_property(TARGET LLVM APPEND_STRING PROPERTY
                 LINK_FLAGS
                 " -compatibility_version 1 -current_version ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}")
   endif()
 
   if(TARGET libLLVMExports)
     add_dependencies(LLVM libLLVMExports)
   endif()
+endif()
 
-if(LLVM_BUILD_LLVM_C_DYLIB)
-  # To get the export list for a single llvm library:
-  # nm ${LIB_PATH} | awk "/T _LLVM/ { print $3 }" | sort -u | sed -e "s/^_//g" > ${LIB_PATH}.exports
-
+if(LLVM_BUILD_LLVM_C_DYLIB AND NOT MSVC)
   if(NOT APPLE)
     message(FATAL_ERROR "Generating libLLVM-c is only supported on Darwin")
   endif()
 
+  if(NOT LLVM_BUILD_LLVM_DYLIB)
+    message(FATAL_ERROR "Generating libLLVM-c requires LLVM_BUILD_LLVM_C_DYLIB on Darwin")
+  endif()
+
+  # To get the export list for a single llvm library:
+  # nm ${LIB_PATH} | awk "/T _LLVM/ { print $3 }" | sort -u | sed -e "s/^_//g" > ${LIB_PATH}.exports
+
   set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_BINARY_DIR}/libllvm-c.exports)
 
   set(LIB_DIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
   set(LIB_NAME ${LIB_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}LLVM)
   set(LIB_PATH ${LIB_NAME}${CMAKE_SHARED_LIBRARY_SUFFIX})
   set(LIB_EXPORTS_PATH ${LIB_NAME}.exports)
   list(APPEND LLVM_DYLIB_REQUIRED_EXPORTS ${LIB_EXPORTS_PATH})
 
if(LLVM_BUILD_LLVM_C_DYLIB AND NOT MSVC)
   target_link_libraries(LLVM-C PUBLIC LLVM)
   add_dependencies(LLVM-C libLLVMCExports)
   
   set_property(TARGET LLVM-C APPEND_STRING PROPERTY
               LINK_FLAGS
               " -compatibility_version 1 -current_version ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH} -Wl,-reexport_library ${LIB_PATH}")
 endif()
 
+if(MSVC)
+  # Build the LLVM-C.dll library that exports the C API.
+
+  set(LLVM_LINK_COMPONENTS
+    ${LLVM_DYLIB_COMPONENTS}
+    )
+
+  llvm_map_components_to_libnames(LIB_NAMES ${LLVM_DYLIB_COMPONENTS})
+  list(REMOVE_DUPLICATES LIB_NAMES)
+
+  # The python script needs to know whether symbols are prefixed with underscores or not.
+  if(LLVM_HOST_TRIPLE STREQUAL "i686-pc-win32")
+    set(GEN_UNDERSCORE "--underscore")
+  else()
+    set(GEN_UNDERSCORE "")
+  endif()
+
+  # Get the full name to the libs so the python script understands them.
+  foreach(lib ${LIB_NAMES})
+    list(APPEND FULL_LIB_NAMES ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib/${lib}.lib)
+  endforeach()
+
+  # Generate the exports file dynamically.
+  set(GEN_SCRIPT ${CMAKE_CURRENT_SOURCE_DIR}/gen-msvc-exports.py)
+
+  set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/libllvm-c.exports)
+
+  add_custom_command(OUTPUT ${LLVM_EXPORTED_SYMBOL_FILE}
+    COMMAND ${PYTHON_EXECUTABLE} ${GEN_SCRIPT} ${FULL_LIB_NAMES} ${GEN_UNDERSCORE} --nm ${LLVM_TOOLS_BINARY_DIR}/llvm-nm -o ${LLVM_EXPORTED_SYMBOL_FILE}
+    DEPENDS ${LIB_NAMES} llvm-nm
+    COMMENT "Generating export list for LLVM-C"
+    VERBATIM )
+
+  # Finally link the target.
+  add_llvm_library(LLVM-C SHARED ${SOURCES} DEPENDS intrinsics_gen)
+
+endif()

tools/llvm-shlib/gen-msvc-exports.py

+#===- gen-msvc-exports.py - Generate C API export file -------*- python -*--===#
+#
+#                     The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+#
+#===------------------------------------------------------------------------===#
+#
+# Generate an export file from a list of given LIB files. This only exports symbols
+# that start with LLVM, so it only exports the LLVM C API.
+#
+# To have CMake run this, set LLVM_BUILD_LLVM_C_DYLIB to on while
+# building on Windows.
+#
+# To run manually, build LLVM with Visual Studio, use a Command prompt
+# to navigate to the directory with the .lib files (Debug\lib etc). Then run
+#     python C:\Path\To\gen-msvc-exports.py --nm ..\bin\llvm-nm.exe LLVM*.lib
+#
+# If you're generating a 32 bit DLL, use the `--underscore` flag.
+# If you want to use a different `llvm-nm` executable, pass the path
+# with the `--nm` flag.
+#
+# You can use the --output flag to set the name of the export file.
+#
+#===------------------------------------------------------------------------===#
+from tempfile import mkstemp
+from contextlib import contextmanager
+from subprocess import check_call
+import argparse
+import os
+import re
+
+
+_UNDERSCORE_REGEX = {
+    False: re.compile(r"^\w+\s+T\s+(LLVM.*)$"),
+    True:  re.compile(r"^\w+\s+T\s+_(LLVM.*)$")
+}
+
+
+@contextmanager
+def removing(path):
+    try:
+        yield path
+    finally:
+        os.unlink(path)
+
+
+def touch_tempfile(*args, **kwargs):
+    fd, name = mkstemp(*args, **kwargs)
+    os.close(fd)
+    return name
+
+
+def gen_llvm_c_export(output, underscore, libs, nm):
+    """Generate the export file for the LLVM-C DLL.
+
+    Run `nm` for each lib in `libs`, and output an export file
+    to `output`. If `underscore` is true, symbols will
+    be assumed to be prefixed with an underscore.
+    """
+    with removing(touch_tempfile(prefix='dumpout', suffix='.txt')) as dumpout:
+
+        # Get the right regex.
+        p = _UNDERSCORE_REGEX[underscore]
+
+        with open(output, 'w+t') as output_f:
+
+            # For each lib get the LLVM* functions it exports.
+            for lib in libs:
+                # Call dumpbin.
+                with open(dumpout, 'w+t') as dumpout_f:
+                    check_call([nm, '-g', lib], stdout=dumpout_f)
+
+                # Get the matching lines.
+                with open(dumpout) as dumpbin:
+                    for line in dumpbin:
+                        m = p.match(line)
+                        if m is not None:
+                            output_f.write(m.group(1) + '\n')
+
+
+def main():
+    parser = argparse.ArgumentParser('gen-msvc-exports')
+
+    parser.add_argument(
+        '-o', '--output', help='output filename', default='LLVM-C.exports'
+    )
+    parser.add_argument('-u', '--underscore',
+        help='labels are prefixed with an underscore (use for 32 bit DLLs)',
+        action='store_true'
+    )
+    parser.add_argument(
+        '--nm', help='path to the llvm-nm executable', default='llvm-nm'
+    )
+    parser.add_argument(
+        'libs', metavar='LIBS', nargs='+', help='list of libraries to generate export from'
+    )
+
+    ns = parser.parse_args()
+
+    gen_llvm_c_export(ns.output, ns.underscore, ns.libs, ns.nm)
+
+
+if __name__ == '__main__':
+    main()