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 <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@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@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
