[PATCH] D16760: Add support for importing and exporting Registry objects on Windows

[Ehsan Akhgari via llvm-commits]

ehsan added inline comments.

================
Comment at: include/llvm/Support/Registry.h:172
@@ +171,3 @@
+  REGISTRY_CLASS::import(DL, #REGISTRY_CLASS)
+#endif
+
----------------
ehsan wrote:
> rnk wrote:
> > ehsan wrote:
> > > rnk wrote:
> > > > Do you think we should have an #else block here that defines these macros to nothing on Unix, so that clients don't have to do the platform ifdefs?
> > > That sounds like a good idea.  (FWIW I'm really unhappy that we needed to change the client side API for this, but sadly there is no way to avoid that.)
> > What if we kept the export side (the non-client side) the same and changed the Registry constructor to do dynamic lookup in all loaded DLLs for the exported symbol? Then we'd only have to change clang and opt.
> Do you mean the Registry constructor running in the plugin to look at all loaded modules for a `AddNodeToRegistry` function and call that instead of `add_node()` in this patch to add its registrations to the Registry in clang.exe?  (I'm not sure how opt enters the picture here.)
I tried the following:

* Export a `LLVMRegistery_${REGISTRY_NAME}_AddNode` function from clang.exe.
* Get `Registry::Add()` to look up the function above from all of the loaded modules using `DynamicLibrary` to find the correct version of the function no matter whether the call is being made from clang.exe or the plugin DLL.

The problem is that in order to look up the correct function name, we need to have the name of the `Registry` as a string at runtime.  This means that given a client doing something like `FrontendPluginRegistry::Add<MyAction>()` needs to somehow be passing "FrontendPluginRegistry" as a string but that's not possible without changing the client code.  And if we're going to change the client code, I prefer to keep using the current approach as it's more similar to the normal way of doing things on Windows.


http://reviews.llvm.org/D16760