[cfe-dev] [PATCH] plugin problem on Windows
thakis at chromium.org
Fri Feb 11 13:39:15 PST 2011
Can't you weak-link the clang libs to your plugin? That's how it's done on
OS X I think.
On Feb 11, 2011 1:18 PM, "John Thompson" <john.thompson.jtsoftware at gmail.com>
> 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
> of the clang library code and data, such that the plug-in registry node
> 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
> 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
> 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 Thompson
> John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev