[PATCH] D30107: Refactor DynamicLibrary so searching for a symbol will have a defined order and libraries are properly unloaded when llvm_shutdown is called.

[Eli Friedman via Phabricator via llvm-commits]

efriedma added inline comments.


================
Comment at: llvm/trunk/include/llvm/Support/DynamicLibrary.h:61
     /// This function permanently loads the dynamic library at the given path.
-    /// The library will only be unloaded when the program terminates.
+    /// The library will only be unloaded when llvm_shutdown() is called.
     /// This returns a valid DynamicLibrary instance on success and an invalid
----------------
marsupial wrote:
> efriedma wrote:
> > marsupial wrote:
> > > efriedma wrote:
> > > > marsupial wrote:
> > > > > efriedma wrote:
> > > > > > Is this change necessary?  I don't see any discussion of this in the review.
> > > > > > 
> > > > > > In addition to being used by the JIT, this API is used to load plugins, and unloading a plugin during llvm_shutdown() can cause a segfault, depending on the order globals get destroyed.
> > > > > I can see the benefit of DynamicLibrary::HandleSet::~HandleSet iterating in reverse order, but having LLVM release memory when I explicitly tell it I'm not using LLVM anymore is important.
> > > > > 
> > > > > Not releasing / deallocating the libraries seems to be a violation of the documentation:
> > > > > "When you are done using the LLVM APIs, you should call llvm_shutdown() to deallocate memory used for internal structures."
> > > > > 
> > > > > If there are issues with plugins wouldn't it better handled in the plugin interface with a way to signal shutdown will/is occurring.
> > > > Adding an interface to notify plugins of an impending shutdown wouldn't help. The problem is that llvm_shutdown itself tries to call into code in the plugin, and there's no way to unregister those handlers.  It might be possible to refactor a bunch of code to allow unloading a plugin without calling llvm_shutdown, but that would be complicated, for little benefit.
> > > > 
> > > > Maybe we could delay unloading shared libraries until other code like the pass manager finishes shutdown?
> > > Do you have an example of this?
> > > 
> > > llvm_shutdown destroys in reverse order of construction so I don't get how a plugin could register a ManagedStatic that would be destroyed before the library is unloaded.
> > It's not a ManagedStatic in the plugin.  The plugin has an llvm::RegisterStandardPasses in it, which calls PassManagerBuilder::addGlobalExtension, which sticks an std::function into the GlobalExtensions with a vtable in the plugin.
> PassManagerBuilder::addGlobalExtension has exactly one line of implementation, storing the passed arguments into a ManagedStatic. Perhaps the problem is a poor usage of that ManagedStatic in other places, forcing it's construction earlier than necessary.
> 
> https://reviews.llvm.org/D33381 addresses the possibility of that bad ordering.
> 
That doesn't help my problem: we also have uses of RegisterManagedStatic in statically linked code.


Repository:
  rL LLVM

https://reviews.llvm.org/D30107