[PATCH] Implement a sane plugin API for clang

[Thompson, John]

Hi Matthew,

Could you point me to more information on how you got the plug-in mechanism to work with clang on Windows?

I understand the need to add access functions for static data, but I don't understand how you build the plugin DLL in general.

How does a clang.exe built from statically-linked libraries have the necessary exports to satisfy the dynamic loading of the plugin DLL?

How do you get the list of symbols to import in the plugin DLL build?  Do you manually collect it from a bare link of the plug-in .obj's with no library references?

Or did you succeed in building a DLL-based version of clang? (Not one big clang DLL like I was experimenting with, but the normal libraries as DLLs.)  If so, how did you do the exports and imports in general?

Doing so without declspec(import/export) seemed problematic because of the 16K limit on the number of exports or some-such.  I know exporting everything in one big DLL would exceed that, but I'm not sure about separate DLLs.

How do you register the plugin's action?  In my hack, I had to have the plugin DLL provide a named function derived from the plug-in name in order for clang to find it.

Thanks.

-John

From: Gao, Yunzhong
Sent: Wednesday, March 20, 2013 2:42 PM
To: Thompson, John
Cc: 'Matthew Curtis'; 'cfe-commits at cs.uiuc.edu'
Subject: RE: [PATCH] Implement a sane plugin API for clang

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> [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<mailto: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/20130321/5e6f1b8c/attachment.html>