walter-erquinigo wrote: > I think I'm missing something. The API's you are calling the lldb_plugin > API's aren't really stand-alone, are they? The lldb_plugin::dwarf API's seem > to have a bunch of methods that take lldb_private types. So you already have > to have some kind of closure of the exported API's that includes whatever > lldb_private types these API's depend on. You're going to be doing picking > and choosing of exports, so I don't see why putting it in another top-level > namespace makes this easier?
You are pretty much right. The picking is mostly about which specific symbols a developer wants to export and prevent an explosion of exported symbols. > I also agree with Jonas, we should reserve lldb_plugin for when we make a > viable API for the more usefully externalized plugins in lldb. So even if we > need another top-level namespace, we should use still use an accurate name > like lldb_plugin_private. After reading twice Jonas' point, I agree with you. Reserving this namespace for such API is definitely very valuable. All in all, I'm now convinced that we should go with `lldb_private::plugin::dwarf`. If I end up having too many symbols to process, I can figure out workarounds, but that's likely not to happen even in a very long time. In any case, is everyone okay if I use the `lldb_private::plugin::dwarf` namespace? https://github.com/llvm/llvm-project/pull/68150 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
