By platform agnostic i mean having a single symbol server that works across multiple platforms is very nice. It sounds like in addition to being a symbol server this can also serve source code, and should work with embedded debug info, split dwo, or even pdb? On Fri, Aug 26, 2016 at 9:54 PM Taras Tsugrii <ttsug...@fb.com> wrote:
> Zachary, I agree that adding a Python dependency might not be a good idea, > so I'll take a closer look at the network code available in lldb. Symbol > format we are currently using is pretty simple - every artifact is > identified by a type (elf, src, etc), an id (build id for binary or hash > for source) and a path. I'm not sure what you mean by platform agnostic, > but with this approach every SymbolVendor will just have to pass the > appropriate type, build id and a path to a ArtifactManager, which will > download or locate a locally cached artifact and return a path to it. > ------------------------------ > *From:* Zachary Turner <ztur...@google.com> > *Sent:* Friday, August 26, 2016 8:18:54 PM > *To:* Taras Tsugrii; lldb-dev@lists.llvm.org > *Cc:* Kevin Frei > *Subject:* Re: [lldb-dev] Symbol Server for everyone. > > 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 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org_2015_01_lldb-2Dis-2Dcoming-2Dto-2Dwindows.html&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jqaYv5aDYHR_MGTz1rkWPg&m=cGDliRKtgFrgnkWwFqxPh4RyRVqdfaAmOCGP-zL_LbA&s=0aQ3fWYzXJkFu8RXsNn-tueEzkRgtHCC53MVc6Mbbqw&e=>), >> 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 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org_2015_01_lldb-2Dis-2Dcoming-2Dto-2Dwindows.html&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jqaYv5aDYHR_MGTz1rkWPg&m=cGDliRKtgFrgnkWwFqxPh4RyRVqdfaAmOCGP-zL_LbA&s=0aQ3fWYzXJkFu8RXsNn-tueEzkRgtHCC53MVc6Mbbqw&e=> >> blog.llvm.org >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jqaYv5aDYHR_MGTz1rkWPg&m=cGDliRKtgFrgnkWwFqxPh4RyRVqdfaAmOCGP-zL_LbA&s=hwDLjBupq4WCB2Tnss4NgxIrkZa-YY8Haze1be8QP9w&e=> >> 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 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jqaYv5aDYHR_MGTz1rkWPg&m=cGDliRKtgFrgnkWwFqxPh4RyRVqdfaAmOCGP-zL_LbA&s=ccEqO276ezHKkpCSnkWigGOXNEbBItPhrrolj22Dr3Y&e=> >> >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
