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

Wed Mar 22 10:26:17 PDT 2023

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