[cfe-dev] [PATCH] plugin problem on Windows

[John Thompson]

Yeah, I tried building a DLL version of Clang using:

cmake -G "Visual Studio 9 2008" -D SHARED_LIBRARY=true .
but Visual Studio 2008 would just hang.

I'm guessing it probably has to do with circular dependencies, which can be
problematic on Windows with DLLs.  But even if it isn't, having Clang be a
bunch of DLLs probably is not a good idea anyway.  Rather than try to figure
it out, maybe the cmake build should be redone to directly build a single
big DLL.  Since I don't know cmake (yet), I'll leave this for your comments.

Since I was able to get a plug-in working with Clang not in a DLL, but not
without a change to the basic mechanism, would this be a reasonable
solution?

Basically, rather than have the plug-in initiate a call to clang, the
plug-in exports a function that Clang calls to get the needed registration
information.

However, this implies some restrictions on the plug-ins, which I don't know
are acceptible.  One is that the plug-in can't directly access global
functions or data in the Clang side; it all has to be through the object
tree passed to the plug-in. This also means that virtual functions in the
object will run in the context of the Clang side, and non-virtual functions
will come from the plug-in side.  Another restriction is that you can't mix
memory allocations, i.e. allocate a block from one runtime that is freed by
the other.  I didn't seem to run into any of these in the Lua bindings
plug-in I did, since it's purely an output mechanism.

Therefore, which should we do, fixing Clang as a single DLL, or the non-DLL
scheme I used?

-John

On Sun, Feb 13, 2011 at 8:00 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:

> John Thompson
> <john.thompson.jtsoftware at gmail.com>
> writes:
>
> > With reference to the Bugzilla 9078 issue I posted, it appears the
> plug-in
> > mechanism doesn't work on Windows.
> >
> > To recap, in loading a Windows plug-in DLL, the DLL will have it's own
> copy
> > of the clang library code and data, such that the plug-in registry node
> list
> > ends up in the DLL and not the Clang executable's data space, hence
> as-is,
> > the plug-ins node doesn't end up in the registry instance in Clang.
>
> A Windows DLL has a single copy of its code and data for a given
> process. But I guess that the problem is that Clang is statically linked
> into every plugin. A proper solution for that is to build Clang as a
> DLL. You can manually do that on MinGW, but not on VC++.
>
> > I've also modified the example.CMakeLists.txt file to build the example
> > projects as part of the main build.
>
> The `examples' directory is optionally added from the toplevel
> CMakeLists.txt file. No need to add it again.
>
> [snip]
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110401/4ee75a49/attachment.html>