<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">{ "type": "symbol-fetch", "basename": "libfoo.so", "uuid": "307E4F5E-EB63-3CC8-B940-9F89BB46098D", "arch": "armv7-apple-ios" }</div><div class=""><br class=""></div><div class="">and it could respond with success:</div><div class="">{ "status": "success", "path": "/path/to/cache/.../debug/info/libfoo.so" }</div><div class=""><br class=""></div><div class=""><div class="">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 class=""><br class=""></div><div class=""><a href="http://lldb.llvm.org/use/symbols.html" class="">http://lldb.llvm.org/use/symbols.html</a></div><div class=""><br class=""></div></div><div class=""><div class="">We specified the "arch" in the original packet so we can have one or more symbol servers registered with the LLDB settings:</div><div class=""><br class=""></div><div class="">(lldb) setting append target.symbol-servers /path/to/ios-symbol-server</div><div class="">(lldb) setting append target.symbol-servers /path/to/linux-symbol-server</div><div class=""><br class=""></div><div class="">and each binary could respond with an status stating that the binary isn't support by a plugin:</div></div><div class=""><br class=""></div><div class="">{ "status": "unsupported" }</div><div class=""><br class=""></div><div class="">or return an error if we found the right plug-in but the file wasn't available for some reason:</div><div class=""><br class=""></div><div class="">{ "status": "failed", "error": "file not available in ..." }<br class=""><div><br class=""></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 class=""></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 class=""></div><div>{ "type": "register" }</div><div><br class=""></div><div>And they could respond with a list of supported triples or other data:</div><div><br class=""></div><div>{ "supported-arch": [ "*-apple-macos", "*-apple-ios", "*-tvos-ios" ] }</div><div><br class=""></div><div>Comments?</div><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 24, 2019, at 11:11 PM, Murali Venu Thyagarajan via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello,<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Thanks,<br class="">Murali</div></div>
_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<br class=""></div></blockquote></div><br class=""></div></body></html>