[lldb-dev] Symbol Server for LLDB

[Adrian McCarthy via lldb-dev]

I know several people here have been looking for a generic, cross-platform
way to locate symbols.  One idea here was to make the symbol fetcher a
Python script that could use the SBAPI to interrogate the debugger to
determine what's needed.  This isn't that different than a separate binary,
but it might make it easier for users to customize it for their environment.

Anyway, I like the idea of a query out to possibly user-provided symbol
fetcher, regardless of the details.

On Fri, Jul 12, 2019 at 3:29 PM Greg Clayton via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> This is currently handled in each Platform subclass. The only platform
> that has the ability to locate symbol automatically are the Darwin
> platforms and those use DebugSymbols.framework to locate the symbols.
>
> That being said, I have been thinking about doing this in a generic way
> that would work for all platforms. My idea is to allow a setting that would
> be set that could specify a executable that would get run with arguments
> that specify the data to be looked up. My first inclination was we would
> pass down a JSON request, and the executable would try to fetch the binary
> requested the JSON, and responsd with a JSON reply specifying where the
> symbols were fetched locally (or made available on a network mount). So we
> might send JSON request that looks something like:
>
> { "type": "symbol-fetch", "basename": "libfoo.so", "uuid":
> "307E4F5E-EB63-3CC8-B940-9F89BB46098D", "arch": "armv7-apple-ios" }
>
> and it could respond with success:
> { "status": "success", "path": "/path/to/cache/.../debug/info/libfoo.so" }
>
> We can include more details in here, like the source path remapping that
> might need to happen so paths can be remapped and used in LLDB to display
> the sources correctly. For info on how we did this for
> DebugSymbols.framework on Darwin see:
>
> http://lldb.llvm.org/use/symbols.html
>
> We specified the "arch" in the original packet so we can have one or more
> symbol servers registered with the LLDB settings:
>
> (lldb) setting append target.symbol-servers /path/to/ios-symbol-server
> (lldb) setting append target.symbol-servers /path/to/linux-symbol-server
>
> and each binary could respond with an status stating that the binary isn't
> support by a plugin:
>
> { "status": "unsupported" }
>
> or return an error if we found the right plug-in but the file wasn't
> available for some reason:
>
> { "status": "failed", "error": "file not available in ..." }
>
> The idea is the Platform.cpp would be the one that would run these scripts
> if the settings were set.
>
> If we want to get really fancy the symbol-server binaries could also be
> asked to return a list of supported target triples so we could avoid call
> all of the symbol servers in the "target.symbol-servers" list. So we would
> ask each symbol server to register itself:
>
> { "type": "register" }
>
> And they could respond with a list of supported triples or other data:
>
> { "supported-arch": [ "*-apple-macos", "*-apple-ios", "*-tvos-ios" ] }
>
> Comments?
>
> On Mar 24, 2019, at 11:11 PM, Murali Venu Thyagarajan via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>
> Hello,
>
> Is there a way to setup a symbol server for lldb just like how I could
> setup a centralized and indexed symbol server for Windbg. Please let me
> know.
>
> Thanks,
> Murali
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://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/20190712/e75596d1/attachment.html>