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 https://reviews.llvm.org/D73119/new/ https://reviews.llvm.org/D73119 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
