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

[Nico Weber]

Can't you weak-link the clang libs to your plugin? That's how it's done on
OS X I think.

Nico

(phone)
On Feb 11, 2011 1:18 PM, "John Thompson" <john.thompson.jtsoftware at gmail.com>
wrote:
> 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.
>
> One way to fix it is to have the plug-ins provide a function hook for
> retrieving the node. Since the address look-up function in Clang looks in
> all plug-ins loaded, that means it has to be a uniquely-named function.
> Therefore, perhaps basing it on the plug-in name is a way to go,
>
> I've enclosed a patch that modifies things to do this. It expects the
> plug-in to export a function with a name like "Get_(plug-in name)_Node
that
> returns the node instance. See the modified PrintFunctionNames for an
> example of this. Since the name for the PrintFunctionNames plug-in is
> "print-fns", I have the function lookup code replace '-' with '_' to get a
> legal C name.
>
> I've also modified the example.CMakeLists.txt file to build the example
> projects as part of the main build.
>
> I also needed some changes in the Registry class to add an AddNode
function
> and expose some privates so the plug-in can get at its node.
>
> I've enclosed two patch files, one for the Clang side and one for the LLVM
> side (the Registry hack).
>
> Permission to check it in? Otherwise, please suggest an alternate fix.
>
> -John
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110211/d4f246c1/attachment.html>