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 scripted symbol locatoe per-target and remove support for > symbol download methods(which are target-agnostic) 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
@jimingham Do u agree with having a global level plugin with ability to create multiple symbol locators per Jonas’s suggestion ? https://github.com/llvm/llvm-project/pull/182336 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
