[lldb-dev] Symbol Server for everyone.

[Zachary Turner via lldb-dev]

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), 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160827/f289f4de/attachment-0001.html>