[PATCH] Implement a sane plugin API for clang

[Gao, Yunzhong]

Hi John,
The other day I ran across a post by Matthew of the Polly team and it seems that the Polly
team might have made some progress regarding plug-in support on Windows.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130311/168147.html

Although I do not fully understand their implementation, it sounds like the Polly team was
not trying to add __declspec(dllimport/dllexport) all over the clang/llvm source base. They
used a .def file to export the necessary symbols from the clang executable, and then they
just tried to use the imported symbols without __declspec(dllimport). According to the
MSDN blog entry below, dllimport is not necessary for function calls and is only necessary
for data access. I am cc'ing Matthew in case I misunderstood Polly's implementation.
http://blogs.msdn.com/b/russellk/archive/2005/03/20/399465.aspx?wa=wsignin1.0

I think both the Cygwin and the mingw environments on Windows provide a dlltool
executable that can automate the generation of .def files from either the object files or a
static library. I am not aware of equivalent tools in the Visual Studio package; you may have
to write some scripts to extract and package the symbols if you are using Visual Studio.

HTH,
- Gao


From: cfe-commits-bounces at cs.uiuc.edu [mailto:cfe-commits-bounces at cs.uiuc.edu] On Behalf Of Thompson, John
Sent: Friday, March 15, 2013 6:04 PM
To: cfe-commits at cs.uiuc.edu
Subject: RE: [PATCH] Implement a sane plugin API for clang

Hi Sean,

I missed the discussion, but I saw your message and wanted to find out where things stood on the plug-in API with respect to Windows.

A year or two ago I wrote a plug-in for Clang for generating LUA bindings, and developing on Windows, found that the plug-in mechanism didn't work on Windows, because it relies on how *nix systems do DLLs.  Unfortunately, in Windows land, a plug-in DLL would have to be linked with Clang libraries which are DLLs, and apparently building the Clang libraries as DLLs is problematic, due to the build system and the messy business of importing/exporting symbols.

I managed to skirt the issue by still building the plug-in against the static libraries, and hacking clang to look up call an entry point function with a name based on the plug-in name so it could hook up the objects in the plug-in.  This, of course, was kind of dangerous, because the plugin module and the clang executable would have totally separate static data areas, not to mention the duplicated code segments.

Then I did some work on making a big Clang DLL, to skirt some of the DLL import/export issues, just exporting the symbol references needed between the driver and the library, using some header conventions for handling the exports.  I intended to pursue this further, and try to resolve the clang DLL build issues, but haven't been able to get back to it.

Has anyone else worked on resolving the plugin issues for Windows or the Clang-libraries-as-DLLs build?

-John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130320/e2814e92/attachment.html>