[Lldb-commits] [PATCH] D73119: [lldb/Initializers] Rename plugins to match their entry points
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Wed Jan 22 12:15:04 PST 2020
labath added a comment.
In D73119#1834279 <https://reviews.llvm.org/D73119#1834279>, @JDevlieghere wrote:
> In D73119#1833232 <https://reviews.llvm.org/D73119#1833232>, @labath wrote:
> > As for `AppleObjCRuntime`, I'm not insisting on changing that, though I am wondering if that won't get it your way when autogenerating the initalizers. I'm not fully sure what are your plans for that. If you're going to generate the `#include` lines then it looks like this discrepancy will matter. If you're going the "extern" route, then generating `#include` is not needed and you headers can be called anything. With the global constructor approach (my favourite :P) we wouldn't need to autogenerate anything at all...
> As much as I personally like the idea of the global constructors, I don't see how it could work. There's no guarantee in initialization order, so you might end up initializing some of the plugins before the plugin manager itself is initialized. Although definitely a bug, it has come up in the past that the initialization order amongst the plugins matters as well. Finally, it doesn't offer a solution to terminating them again. Maybe you've already thought about all this?
Registering a plugin consists of putting some pointers into a vector. We just need to make sure the vector is initiailized on first use (which I think it already is) instead of being a global variable. If we wanted to make plugin order explicit we could make each plugin provide some sort of a priority for itself, and sort the vector based on that (but I don't think we really need to do that).
As for termination, that can be solved by passing one additional function pointer in the initialization routine -- the Terminate function. The plugin manager can then automatically call this for all registered plugins. (This would be a nice cleanup independently of everything else.)
That said, I have now found one snag with this approach. The way that the build is setup right now, each plugin first becomes an archive file, which then gets included into liblldb. If liblldb does not require any symbol from the archive file (global constructors don't count), the linker will just ignore it. That is fixable, but it requires either some platform-specific flags (-Wl,--whole-archive for elf), or playing with cmake OBJECT libraries, which look like they could support this, but I don't fully understand how they work. Both of these things make this approach less appealing than I originally thought...
CHANGES SINCE LAST ACTION
More information about the lldb-commits