labath added a comment. In D75750#1953924 <https://reviews.llvm.org/D75750#1953924>, @clayborg wrote:
> The main issue is that the symbol vendors currently are ELF, macOS and WASM. > Right now we have one SymbolVendor for a triple, but I can see a SymbolVendor > wanting to use multiple symbol servers to get information: one for the OS > binaries (debuginfod or DebugSymbols.framework at Apple) and one for the > current application with company specific symbol servers. At Apple, they can > download any symbols for macOS, iOS, watchOS and tvOS OSes and applications. > At Facebook we can download symbols for android, linux and iOS. Linux distros > might have ways to download symbols for their OS stuff, which might work > along side debuginfod? Also windows has the ability to download symbols. > > So it might be good to have the SymbolVendors use one or more SymbolServer > plug-ins. I don't believe we have anything that would require all modules in a given target (or whatever) to use the same symbol vendor type. Each module gets its own instance of the object, which is obtained and manipulated through the generic interface. It is true that our current symbol vendors key off of the triple (more like object file type, really), so all modules ale likely to have the same vendor, but nothing really requires it to be that way. The symbol vendors get a ModuleSP, and they can use any information there to determine whether they are relevant. So if we had multiple symbol vendors interested in say elf files, we would just ask each of them in turn whether they can handle this module, and the first one would "win". Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75750/new/ https://reviews.llvm.org/D75750 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
