[lldb-dev] Symbol Server for everyone.

Fri Aug 26 22:01:30 PDT 2016

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 <ttsugrii at 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 <zturner at google.com>
> *Sent:* Friday, August 26, 2016 8:18:54 PM
> *To:* Taras Tsugrii; lldb-dev at 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 at 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 at 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=>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160827/e127767b/attachment-0001.html>