[Lldb-commits] [lldb] [LLDB][NFC] Create a namespace for the DWARF plugin (PR #68150)

Jonas Devlieghere via lldb-commits lldb-commits at lists.llvm.org
Fri Oct 13 08:06:40 PDT 2023


JDevlieghere wrote:

> Should we have a top level "lldb_plugin" namespace instead of "lldb_private::plugin"? It would be easier to be able to export only a single plug-in interface if needed if we did this

What makes it easier to export `lldb_plugin` than `lldb_private::plugin`? I'm only familiar with using an export list in which case it's just another prefix. 

I also think conceptually this is somewhat confusing or even misleading. We currently have an `lldb` and `lldb_private` namespace which mean very different things. That expectations, combined with the fact that LLDB has plugins, makes it really sound like `lldb_plugin` is the interface we expose for writing (dynamically loadable) plugins. But that's not the case at all, it's actually the opposite: because all the plugins use `lldb_private` in their interfaces, so you need to export `lldb_private` types. Making it a namespace contained in `lldb_private` makes that really obvious.

If we ever want to have somewhat stable language plugins for Swift or Rust, we actually will need something like what I describe above: a "somewhat stable" interface that downstream languages can use to implement their language support without having to maintain a full fork (like Swift). We're still pretty far from that, but I wouldn't want to reserve a namespace now that will only make that harder down the line. 

FWIW I don't feel super strongly about this. I want to understand the benefit of Greg's suggestion because I see a smallish downside to doing it that way and all things being equal we can avoid some confusing in the future. 

https://github.com/llvm/llvm-project/pull/68150


More information about the lldb-commits mailing list