[Lldb-commits] [PATCH] D146553: [lldb][CMake] Enforce not linking against plugin libs in core libs

Thu Mar 23 02:30:58 PDT 2023

> But the command interpreter doesn't "depend" on these plugin commands, it
just vends them.

Right, I'm conflating depending on as in linking to or specifically asking
for a certain plugin, vs. making use of the information that category of
plugins could provide if they are present. Commands don't just crash if
there's no plugin for a certain thing, they just say ok we don't know
anything at this time.

> 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.

Understood. I should take what I want to do and make an API for that task.
Then the "how" goes in a plugin.

On Wed, 22 Mar 2023 at 20:16, Jim Ingham <jingham at apple.com> wrote:

> 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 at 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 at 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 at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> >
> > _______________________________________________
> > lldb-commits mailing list
> > lldb-commits at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20230323/17b84918/attachment-0001.html>