JDevlieghere wrote: There's a few things I don't really like about this patch:
- It's very specific to a single plugin. - It sidesteps the plugin's `Initialize/Terminate` paradigm. It happens to work because `ScriptInterpreterPython::Terminate` is a NOOP (see the comment for `ScriptInterpreterPythonImpl::Terminate` on why). It's not that we don't have other places where things persist after termination, but as we've seen, that can cause problems, for example in unit testing. - It relies on changing the scripting language early enough to make sure the plugin doesn't get loaded. If the code changes and tries to use the plugin before you have the opportunity to call `SetScriptLanguage` you're back to square one. If it's important to disable certain plugins at runtime, I wonder if we shouldn't do this in a more structured way. - We could make the initialization of all plugins lazy. If we're always going through the plugin interface, this should work. The question is if this is beneficial. - We could extend `SBDebugger::Initialize` with a list of plugins to disable. I expect this to be somewhat contentious though, as there are certain plugins that depend on other plugins. We had a long discussion about this when I wrote a patch to do this at compile time, which would have the same limitations as doing it at runtime. - A combination or hybrid of the two, where you can tell which plugins to load lazily and which ones not to load. Can you elaborate on why it's important that the `PythonScriptInterepter` doesn't get initialized? Maybe that can help guide the solution instead of working back from the current patch. https://github.com/llvm/llvm-project/pull/105757 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
