rchamala wrote: > > I asked that this be per target. If target A is a local macOS session and > > target B is a remote Windows session, the symbol locators for those two are > > clearly going to be different. So I need to be able to simultaneously > > attach one symbol locator to target A and a very different one to target B. > > Agreed, but that doesn't necessitate tying the scripted symbol locators to a > target, or at least not the way that it's done here. What you describe can > already work today with the global plugins (and I'm not implying you said it > doesn't, just providing context for @rchamala), where the debuginfod plugin > handles remote Linux and the [Windows Symbol > Server](https://discourse.llvm.org/t/rfc-add-symbollocator-for-windows-pdb-symbol-servers-in-lldb/89877/16) > plugin handles remote Windows. > > The least intrusive solution, matching the current design, would be to keep > the plugins global, and have the option to register multiple scripted ones, > and have each instance of the ScriptedSymbolLocator decide whether they can > handle the request or not. In other words, we support having N scripted > symbol locators and they're only indirectly tied to a target. This would be > my preference, barring a good reason to do it differently. > > The alternative is to either have one scripted symbol locator that does the > multiplexing as part of its implementation, but I don't think that's a great > design as it totally blinds LLDB from what's going on in the implementation. > If a symbol locator being tied to the target is critical, then we should do > that for all the symbol locators, similar to what we do for the language > plugins, and the target should hold onto a list of symbol locator plugins. > The reason I'm not fan of this is because although that makes sense for the > Scripted Symbol Locator, I don't think it's as obvious for something like > debuginfod.
I had originally designed it to be a global symbol scripted locator but following the PR comment, tried to make it per-target which exposes an underlying conflict between symbol-locator plugins which is expected to be global callback using modules itself VS per-target scripted plugins. This also created some performance issues with my previous implementation as I was trying to find the matching target inside the plugin which is target-agnostic. So, I have 2 options that I could think 1. Either make it per-target and remove support for symbol download methods(which are target-agnostic) and used in debuginfod (this PR) 2. Make symbol-locator global and add support for remaining methods @JDevlieghere Based on the concensus from @jinmingjian, I was hoping to get some alignment on the approach. Will then break it down to small PR's once we all agree on the high-level design https://github.com/llvm/llvm-project/pull/182336 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
