That general facility is why we think of plugins as something more than just implementations. Along with the "on load" actions, they also have the job of detecting "Am I the right implementation for this binary, this language, this OS version, etc". That also informs the proper way to use them. You start with something of a particular plugin type you want to work with - a path to a binary or a the language type you got from a StackFrame - which is managed by a particular plugin class, and you first ask the manager for that plugin type "find me the plugin that handles my entity", then call the generic API's on that plugin. You shouldn't dial up particular plugins or call anything but the plugin interface methods on them. If you have to do something that's specific to a particular plugin implementation, that needs to be done inside the plugin, and vended in some neutral way.
Jim > On Mar 22, 2023, at 11:33 AM, Jim Ingham via lldb-commits > <lldb-commits@lists.llvm.org> wrote: > > David, > > I think you were also thinking about things like the `language cplusplus` > commands or the `settings set plugin.***` settings. That isn't a case of > generic code depending on specific plugin implementations. Rather that's a > general feature of the plugin loader, it queries the plugin to see if it has > any commands or settings to add to the command interpreter when loaded. But > the command interpreter doesn't "depend" on these plugin commands, it just > vends them. > > Jim > >> On Mar 22, 2023, at 10:26 AM, Alex Langford via Phabricator via lldb-commits >> <lldb-commits@lists.llvm.org> wrote: >> >> bulbazord added a comment. >> >> In D146553#4212417 <https://reviews.llvm.org/D146553#4212417>, >> @DavidSpickett wrote: >> >>> Is this policy documented anywhere? Perhaps you can update one of the >>> design pages if it isn't already there. >>> >>> Because I am a bit confused about it. Some parts of lldb use plugins and >>> those parts are called by commands through a few other layers. However >>> commands can't link to the plugins directly, but some of them do show >>> information that further down came from a plugin. I'm wondering what the >>> best practices are (and some examples would be great!). >> >> This policy is not really documented anywhere. I've been working towards >> making the non-plugins not depend on any plugins for a few years now (along >> with some other folks, some of whom are no longer working on LLDB). As for >> updating one of the design pages, I think I'll update this one: >> https://lldb.llvm.org/design/overview.html >> Currently, we are down to maybe 3-4 places where we're using plugins in >> non-plugin contexts and I have a few plans to remove those dependencies. >> They're a bit challenging to remove so I'll be moving a bit more carefully. >> >> I can understand the confusion. Navigating LLDB's design is quite >> challenging because a lot of it is kind of ad-hoc and grew organically while >> some transitions from one thing to another weren't always completed 100%. I >> personally think that the name "plugin" is a bit misleading because they're >> not really things you can add/remove at runtime. You can't really even >> add/remove them at CMake configure time (though there was some interest in >> doing this in the past). I think a name better than "plugin" would be >> "implementation" because that's what the plugins are: specific >> implementations of more general debugger concepts (e.g. ABI support, >> Platforms, Languages and LanguageRuntimes, ObjectFiles, etc). >> >> As for best practices, I suppose that depends on exactly which plugin you're >> using. If the goal is just to get some information from a relevant plugin, >> you can look at the way the Language plugins are designed. The Language >> class in `lldb/source/Target/` has several functions like "FindPlugin" and >> "ForEach" which let you find the correct plugin for a language and operate >> over all known language plugins respectively. A slightly different model >> might be how the TypeSystems work. To get a scratch TypeSystem for example, >> we usually go through the `Target` that we have with >> `Target::GetScratchTypeSystemForLanguage` or something to this effect. I >> suppose it just depends on what you're trying to do, which I realize may not >> be the most helpful advice but I hope that with enough examples it becomes >> at least a little more clear how things in lldb are currently done... >> >> One thing you may notice as you use and extend these plugins is that the >> base class for the plugin you're working with may not be able to support >> your use case. In this case, it may make sense to extend the interface to >> support your use case. The existing interfaces (e.g. TypeSystem) only >> support what has needed to be done up until now, so there may be a use case >> that makes sense that nobody bothered to add before. In other cases, it may >> make sense to rely on specific implementation details in said plugins. >> Ideally we would not be doing that in non-plugins as those are supposed to >> be more general though and maybe we can figure out a way to do it in a >> plugin instead. >> >> This is all very off the cuff. I hope it makes sense and helps. I will be >> updating the design document (and I'll add you as a reviewer). >> >> >> Repository: >> rG LLVM Github Monorepo >> >> CHANGES SINCE LAST ACTION >> https://reviews.llvm.org/D146553/new/ >> >> https://reviews.llvm.org/D146553 >> >> _______________________________________________ >> lldb-commits mailing list >> lldb-commits@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > > _______________________________________________ > lldb-commits mailing list > lldb-commits@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
