-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Load plugins in-process. #78
base: master
Are you sure you want to change the base?
Conversation
// Load any requested plugins. | ||
for (const auto &path : plugins) { | ||
std::string error; | ||
if (llvm::sys::DynamicLibrary::LoadLibraryPermanently(path.c_str(), &error)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like LLVM is able only to load library permanently and not to unload:
Note: there is currently no interface for temporarily loading a library
But the in-process mode of the compiler implies that it is always in memory and might live as long as the Runtime by which it's invoked. It also means that compilation might be called (and is called) multiple times for different sources and with different options, including options for loading plugins. I believe that we should load plugins per one compilation (clang::driverCompilation class instance).
So we need a solution for unloading plugin library. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I'm unsure if there is a specific reason that there is no interface for temporarily loading a library. It looks like libraries are unloaded when llvm::llvm_shutdown is called. AFAICS with AMDOCL in-process llvm_shutdown is never called. We cannot call llvm_shutdown after each compilation because it will effect more than just loaded libraries. So I guess one option would be to re-initialize LLVM before each compilation so that llvm_shutdown can be called.
I don't think there is a good solution for unloading a plugin library without patching LLVM. I tried something like this:
void DynamicLibrary::UnloadLibraries() {
SmartScopedLock<true> Lock(*SymbolsMutex);
//
// We would also need to Lock ManagedStaticMutex
// here I guess.
//
// Unload dynamic libraries by destroying HandleSet.
if (OpenedHandles.isConstructed())
OpenedHandles.destroy();
}
The call to ::dlclose doesn't necessarily unload the library, because it seems like I can still use the plugin for the next clang::driverCompilation even without reloading it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about switching off in-process in case of loading plugin(s) (as long as it seems there is no solution for temporary loading plugins from libraries, at least yet)?
Btw, llvm_shutdown needs LLVM (re)initialization, but it also doesn't work since llvm_shutdown was designed to be called just before application termination and actually does not imply further work with LLVM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about switching off in-process in case of loading plugin(s)
I like this idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, let's leave the change with in-process for a while, and make instead switching in-process off in case of loading plugin (corresponding options are found) and switching in-process back on after finishing compilation. In case of in-process off do nothing.
Clang "-load" and "-fplugin" options are ignored when using the driver with "in-process" configuration.
Attempt to load plugins in "PrepareCompiler".