<div dir="ltr">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.<div><br></div><div>Anyway, I like the idea of a query out to possibly user-provided symbol fetcher, regardless of the details.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 12, 2019 at 3:29 PM Greg Clayton via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">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.<div><br></div><div>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:</div><div><br></div><div>{ "type": "symbol-fetch", "basename": "libfoo.so", "uuid": "307E4F5E-EB63-3CC8-B940-9F89BB46098D", "arch": "armv7-apple-ios" }</div><div><br></div><div>and it could respond with success:</div><div>{ "status": "success", "path": "/path/to/cache/.../debug/info/libfoo.so" }</div><div><br></div><div><div>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:</div><div><br></div><div><a href="http://lldb.llvm.org/use/symbols.html" target="_blank">http://lldb.llvm.org/use/symbols.html</a></div><div><br></div></div><div><div>We specified the "arch" in the original packet so we can have one or more symbol servers registered with the LLDB settings:</div><div><br></div><div>(lldb) setting append target.symbol-servers /path/to/ios-symbol-server</div><div>(lldb) setting append target.symbol-servers /path/to/linux-symbol-server</div><div><br></div><div>and each binary could respond with an status stating that the binary isn't support by a plugin:</div></div><div><br></div><div>{ "status": "unsupported" }</div><div><br></div><div>or return an error if we found the right plug-in but the file wasn't available for some reason:</div><div><br></div><div>{ "status": "failed", "error": "file not available in ..." }<br><div><br></div><div>The idea is the Platform.cpp would be the one that would run these scripts if the settings were set.</div><div><br></div><div>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:</div><div><br></div><div>{ "type": "register" }</div><div><br></div><div>And they could respond with a list of supported triples or other data:</div><div><br></div><div>{ "supported-arch": [ "*-apple-macos", "*-apple-ios", "*-tvos-ios" ] }</div><div><br></div><div>Comments?</div><div><br><blockquote type="cite"><div>On Mar 24, 2019, at 11:11 PM, Murali Venu Thyagarajan via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_1017951182950061343Apple-interchange-newline"><div><div dir="ltr">Hello,<div><br></div><div>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.</div><div><br></div><div>Thanks,<br>Murali</div></div>
_______________________________________________<br>lldb-dev mailing list<br><a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>