<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>
<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>