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
Not currently (at least, not for the platforms I use primarily), but there is definitely interest in a symbol fetcher so there may be somebody working on it.
Not exactly a full symbol server solution, but LLDB supports the GDB-style symbol lookup (search for the build-ID notes and nn/nnnnnnnn.debug). This, together with a simple NFS setup can get you close to a Microsoft-style symbol store.
This blog post might be relevant too.
As Adrian hints, there’s an interest in adding first class support for symbol servers to LLDB.
Thanks a lot Adrian and Leonard.
I’m interested in setting up a local symbol server for my application that is being built on MacOS. Pretty much like a indexed symbol server that is used with Windows applications with Windbg.
Thanks,
Murali
Another question that I had is,
Can this GDB style be inferred for MacOS packages? Will there be a build-ID in the package and the corresponding dSym package?
Thanks,
Murali
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?
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.