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

Reply via email to