<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Feb 11, 2011, at 1:18 PM, John Thompson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>With reference to the Bugzilla 9078 issue I posted, it appears the plug-in mechanism doesn't work on Windows.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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,</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>I've also modified the example.CMakeLists.txt file to build the example projects as part of the main build.</div>
<div><br clear="all">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.</div>
<div> </div>
<div>I've enclosed two patch files, one for the Clang side and one for the LLVM side (the Registry hack).</div>
<div> </div>
<div>Permission to check it in? Otherwise, please suggest an alternate fix.</div></blockquote><div><br></div><div>I think we should move away from the llvm::Registry mechanism. How about the exported function returns a PluginASTAction*, we store all PluginASTAction* pointers that the plugins return and iterate over them when invoking plugin actions.</div><div><br></div><div>-Argyrios</div><br><blockquote type="cite">
<div> </div>
<div>-John</div>
<div><br>-- <br>John Thompson<br><a href="mailto:John.Thompson.JTSoftware@gmail.com">John.Thompson.JTSoftware@gmail.com</a><br><br></div>
<span><cpluginfix.patch></span><span><lpluginfix.patch></span>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote></div><br></body></html>