Making the SymbolVendor dependent on Python is probably a non starter, and it would also make debugging more difficult.
We have network code for various platforms in Host already. It would be nice to have a symbol server format that is platform agnostic. On the other hand, Microsoft tools already understand their own symbol server format , so if i ever reprioritize this, we will probably want the standard Microsoft symbol server format on Windows for interoperability. On Fri, Aug 26, 2016 at 8:00 PM Taras Tsugrii via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello lldb developers, > > > In one of the older posts ( > http://blog.llvm.org/2015/01/lldb-is-coming-to-windows.html), symbol > server support was mentioned. Most likely it was meant for Windows, but at > FB we have our own symbol server implementation for Linux (technically it's > completely platform agnostic), which we would like to integrate with LLDB > and eventually open source along with the server. As such I thought I'd ask > LLDB gurus like you, if anyone is already working on symbol server support > and if not, I'd appreciate your thoughts on a desired architecture. > > > General idea. > > Based on current LLDB implementation and the fact that symbol server > feature is a cross-cutting concern, the natural place to put this logic > would be inside SymbolVendor plugin, which on Mac is used to resolve > separate dSYM bundles. In theory symbol server logic is completely > platform-agnostic, as all we need to know is some sort of binary ID (could > either be a real .build-id or UUID or some custom logic to compute a stable > binary hash) and binary name. This info can be used to make a network > request to check whether corresponding binary exists and if so, download it > to a temporary location and call symbol_vendor->AddSymbolFileRepresentation > with FileSpec pointing at that temporary location. > > > Implementation details. > > > Logic placement. > > Even though symbol resolution is platform agnostic, the process of > extracting/computing binary ID is. As such it seems like > SymbolServerResolver can either be a part of LLDB core, or a separate > directory in Plugins/SymbolVendor, which will then be used by > SymbolVendorELF and SymbolVendorMacOSX. First both symbol vendors will try > to resolve the symbols the way they currently do and only if they cannot > find anything, will they try to use SymbolVendorSymbolServer. > > Alternatively symbol server resolution logic can be placed into its own > SymbolVendorSymbolServer, and modify SymbolVendor FindPlugin's logic such > that it does not return the first found SymbolVendor instance and instead > returns either the first SymbolVendor instance that managed to successfully > resolve symbols or just last one. > > Yet another alternative would be to use a delegation chain, such that any > SymbolVendor could be wrapped into a SymbolVendorSymbolServer, which would > first try to invoke the delegate and if it cannot find symbols, will try to > perform its magic. This approach seems nice, but does not play nice with > current implementation based on static factory method. > > > Symbol server communication. > > Network communication can either be implemented natively for different > platforms or it can be delegated to a python script invoked by > ScriptInterpreter. Using Python seems an easier option in order to make > this cross-platform, but it adds a dependency on Python and will require > propagating ScriptInterpreter to SymbolVendor creation factory. > > > Thoughts, suggestions and comments are very welcome. > > > Thank you, > > Taras > LLVM Project Blog: LLDB is Coming to Windows > <http://blog.llvm.org/2015/01/lldb-is-coming-to-windows.html> > blog.llvm.org > This preliminary bootstraping work is mostly complete, and you can use > LLDB to debug simple executables generated with Clang on Windows today. > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev