How to build and run a Clang plugin in windows

Question

I have cloned the llvm-project repository.

Then I have generated a Visual Studio solution for the project using

cmake -G "Visual Studio 16" -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON -DLLVM_TARGETS_TO_BUILD=X86 -DCLANG_BUILD_EXAMPLES=ON -DCMAKE_INSTALL_PREFIX=install ...\llvm-project\llvm

The important part is the DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS, as suggested here.

The solution and all the projects are generated. Then I build Clang itself and an example clang plugin that is already provided in the llvm-project source. The PrintFunctionNames seem to be the hello world of Clang plugins, so I have built that, according to the llvm documentation.

The build successfully ran, and now I have llvm/clang in the install dir, with the PrintFunctionNames plugin.

There are two ways to tell clang to use a plugin:

clang -cc1 -load PrintFunctionNames.dll -plugin print-fns test.cpp
clang++ -c -Xclang -load -Xclang PrintFunctionNames.dll -Xclang -plugin -Xclang print-fns test.cpp

The first one works, however, the second one doesn't. Moreover, using clang++ with the first command line arguments won't work either. Both commands work with clang but neither with clang++, so it would seem that there's a problem with clang++. Also, omitting the -c command and actually building an executable with a plugin active yields a link error (1137).

It seems like clang++ doesn't work with dll plugins, which is quite weird as clang++ seems to be the same clang driver, except with different presets for linking with c++ libraries.

Another problem I have encountered was that when building out-of-tree, the cmake install command fails to copy over a library file, clang.lib to the install dir, without which out-of-tree plugins can't be built. Manually setting the path for this library (that resides in the original output directory, not where cmake install would move the other build outputs) seems to allow out-of-tree plugins to be correctly built.

But the problem persists: you can not use Xclang plugin loader or the clang++ driver with plugins on windows. Not with the provided example plugin, not with a test plugin a made out-of-tree.

The question is: am I building clang or the plugins wrong somehow? If so, how come -cc1 -load can use the plugins with clang.exe? How does one build the provided example plugin and have it work with the clang++ driver? I have looked at this GitHub repo which implements a basic out-of-tree plugin, but it doesn't provide any information on building on windows.

Answer 1

This is NOT the correct answer, but rather a workaround of the problems encountered.

While I did not get clang++ to work properly with any example plugins, I have a bit of a better understanding of the problem now.

What complicates things is Windows. In order to have clang symbols available to the plugin, clang needs to build a special clang.lib file, that contains those symbols, since there is no mechanism of using a executable's symbols from a dynamic library on Windows. That is great, linking this extra library (that does not get copied over on the cmake INSTALL command!) enables plugins to be built. But then any plugins must include the necessary libs that clang builds and defines in the CMakeLists file. For the PrintFunctionNames example pluging, these are defined as such:

clang_target_link_libraries(PrintFunctionNames PRIVATE
    clangAST
    clangBasic
    clangFrontend
    )

However, something goes wrong with the Visual Studio project generation and only the exported symbol library, clang.lib gets included. You need to manually add these libraries if you would like to not only use the plugin but have clang build the source files (these links are needed to resolve the linking error 1136).

However, linking clangFrontend messes up the plugin registration mechanism, making a second plugin registry for the plugin, which is dumb. So clangFrontend must NOT be included in plugins. But everything else it needs MUST be linked in, even if cmake doesn't generate the project with such settings, to have the compiler not throw linking errors.

As for clang++ still not working: I have looked at the build steps of clang extensively and found that clang.exe just gets copied over as clang++.exe as a post-build step. Since the binaries are exactly the same size, I wonder if there is any difference at all. As far as I know, you can compile C++ code with just the clang.exe compiler (driver), so using only the clang.exe seems to be fine. However, IDE integration, external projects that expect clang++ can not use plugins, so there is that. Perhaps redirecting clang++ calls with symlinks could be a hack to work around that issue.

Answer 2

I'm pretty sure this can never work, due to the rather large difference between how a .so file is linked in Linux (pretty much like a static library) while a DLL is much more separated from the loading module. This means that the Registry static members will be separate for each DLL and the actual registrations will not be known to clang.exe.

I did attempt to solve this by adding a C function in the DLL that could return the list of plugin object type registered. This got the plugin registered but it absolutely did NOT work as the AST traversal mechanism relies on comparing addresses of singleton objects, and with the DLL system these singletons are duplicated in each DLL, leading to asserts as no address matches. In my case there was a floating point type that failed to be found as the address of two content-wise equal objects were compared. My guess is that there are lots of such problems, and not worth pursuing.

What I ended up doing was to just link my plugin statically to the clang driver and that worked, but note that you must either link it as an obj file directly to the exe project or make sure to refer to some entity declared in it from for instance the main module. This ensures that the static object adding the plugin is actually included in the link.