<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Yes, Zachary, design does not have any platform constraints, as long as we have a reliable way to identify a binary, which can always be arranged.</p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Zachary Turner <zturner@google.com><br>
<b>Sent:</b> Friday, August 26, 2016 10:01:30 PM<br>
<b>To:</b> Taras Tsugrii; lldb-dev@lists.llvm.org<br>
<b>Cc:</b> Kevin Frei<br>
<b>Subject:</b> Re: [lldb-dev] Symbol Server for everyone.</font>
<div> </div>
</div>
<div>By platform agnostic i mean having a single symbol server that works across multiple platforms is very nice. It sounds like in addition to being a symbol server this can also serve source code, and should work with embedded debug info, split dwo, or even
pdb?<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Aug 26, 2016 at 9:54 PM Taras Tsugrii <<a href="mailto:ttsugrii@fb.com">ttsugrii@fb.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div id="m_7515340863614851877divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<div id="m_7515340863614851877divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Zachary, I agree that adding a Python dependency might not be a good idea, so I'll take a closer look at the network code available in lldb. Symbol format we are currently using is pretty simple - every artifact is identified by a type (elf, src, etc), an
id (build id for binary or hash for source) and a path. I'm not sure what you mean by platform agnostic, but with this approach every SymbolVendor will just have to pass the appropriate type, build id and a path to a ArtifactManager, which will download or
locate a locally cached artifact and return a path to it.</p>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_7515340863614851877divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>><br>
<b>Sent:</b> Friday, August 26, 2016 8:18:54 PM<br>
<b>To:</b> Taras Tsugrii; <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">
lldb-dev@lists.llvm.org</a><br>
<b>Cc:</b> Kevin Frei<br>
<b>Subject:</b> Re: [lldb-dev] Symbol Server for everyone.</font>
<div> </div>
</div>
</div>
</div>
<div dir="ltr">
<div id="m_7515340863614851877divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<div>Making the SymbolVendor dependent on Python is probably a non starter, and it would also make debugging more difficult.<br>
<br>
We have network code for various platforms in Host already.<br>
<br>
It would be nice to have a symbol server format that is platform agnostic. On the other hand, Microsoft tools already understand their own symbol server format , so if i ever reprioritize this, we will probably want the standard Microsoft symbol server format
on Windows for interoperability.<br>
<br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Aug 26, 2016 at 8:00 PM Taras Tsugrii via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div id="m_7515340863614851877m_1763027943659039358divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hello lldb developers,</p>
<p><br>
</p>
<p>In one of the older posts (<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org_2015_01_lldb-2Dis-2Dcoming-2Dto-2Dwindows.html&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jqaYv5aDYHR_MGTz1rkWPg&m=cGDliRKtgFrgnkWwFqxPh4RyRVqdfaAmOCGP-zL_LbA&s=0aQ3fWYzXJkFu8RXsNn-tueEzkRgtHCC53MVc6Mbbqw&e=" class="m_7515340863614851877m_1763027943659039358OWAAutoLink" id="m_7515340863614851877m_1763027943659039358LPlnk894957" target="_blank">http://blog.llvm.org/2015/01/lldb-is-coming-to-windows.html</a>),
symbol server support was mentioned. Most likely it was meant for Windows, but at FB we have our own symbol server implementation for Linux (technically it's completely platform agnostic), which we would like to integrate with LLDB and eventually open source
along with the server. As such I thought I'd ask LLDB gurus like you, if anyone is already working on symbol server support and if not, I'd appreciate your thoughts on a desired architecture.</p>
<p><br>
</p>
<p>General idea.</p>
<p>Based on current LLDB implementation and the fact that symbol server feature is a cross-cutting concern, the natural place to put this logic would be inside SymbolVendor plugin, which on Mac is used to resolve separate dSYM bundles. In theory symbol server
logic is completely platform-agnostic, as all we need to know is some sort of binary ID (could either be a real .build-id or UUID or some custom logic to compute a stable binary hash) and binary name. This info can be used to make a network request to check
whether corresponding binary exists and if so, download it to a temporary location and call <span>symbol_vendor->AddSymbolFileRepresentation with FileSpec pointing at that temporary location.</span></p>
<p><span><br>
</span></p>
<p><span>Implementation details.</span></p>
<p><span><br>
</span></p>
<p><span>Logic placement.</span></p>
<p><span>Even though symbol resolution is platform agnostic, the process of extracting/computing binary ID is. As such it seems like SymbolServerResolver can either be a part of LLDB core, or a separate directory in Plugins/SymbolVendor, which will then be
used by SymbolVendorELF and SymbolVendorMacOSX. First both symbol vendors will try to resolve the symbols the way they currently do and only if they cannot find anything, will they try to use SymbolVendorSymbolServer.</span></p>
<p>Alternatively symbol server resolution logic can be placed into its own SymbolVendorSymbolServer, and modify SymbolVendor FindPlugin's logic such that it does not return the first found SymbolVendor instance and instead returns either the first SymbolVendor
instance that managed to successfully resolve symbols or just last one.</p>
<p>Yet another alternative would be to use a delegation chain, such that any SymbolVendor could be wrapped into a SymbolVendorSymbolServer, which would first try to invoke the delegate and if it cannot find symbols, will try to perform its magic. This approach
seems nice, but does not play nice with current implementation based on static factory method.</p>
<p><span><br>
</span></p>
<p><span>Symbol server communication.</span></p>
<p><span>Network communication can either be implemented natively for different platforms or it can be delegated to a python script invoked by ScriptInterpreter. Using Python seems an easier option in order to make this cross-platform, but it adds a dependency
on Python and will require propagating ScriptInterpreter to SymbolVendor creation factory.</span></p>
<p><span><br>
</span></p>
<p><span>Thoughts, suggestions and comments are very welcome.</span></p>
<p><span><br>
</span></p>
<p><span>Thank you,</span></p>
<p><span>Taras</span></p>
<div id="m_7515340863614851877m_1763027943659039358LPBorder_GT_14703327535410.5182283317476308" style="margin-bottom:20px;overflow:auto;width:100%;text-indent:0px">
<table id="m_7515340863614851877m_1763027943659039358LPContainer_14703327535380.011026752022188058" cellspacing="0" style="width:90%;overflow:auto;padding-top:20px;padding-bottom:20px;margin-top:20px;border-top:1px dotted rgb(200,200,200);border-bottom:1px dotted rgb(200,200,200);background-color:rgb(255,255,255)">
<tbody>
<tr valign="top" style="border-spacing:0px">
<td id="m_7515340863614851877m_1763027943659039358TextCell_14703327535390.6142181755832397" colspan="2" style="vertical-align:top;padding:0px;display:table-cell">
<div id="m_7515340863614851877m_1763027943659039358LPRemovePreviewContainer_14703327535400.42599437410565977">
</div>
<div id="m_7515340863614851877m_1763027943659039358LPTitle_14703327535400.45860326168279064" style="color:rgb(0,120,215);font-weight:normal;font-size:21px;font-family:wf_segoe-ui_light,"Segoe UI Light","Segoe WP Light","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;line-height:21px">
<a id="m_7515340863614851877m_1763027943659039358LPUrlAnchor_14703327535400.45319532006736085" href="https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org_2015_01_lldb-2Dis-2Dcoming-2Dto-2Dwindows.html&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jqaYv5aDYHR_MGTz1rkWPg&m=cGDliRKtgFrgnkWwFqxPh4RyRVqdfaAmOCGP-zL_LbA&s=0aQ3fWYzXJkFu8RXsNn-tueEzkRgtHCC53MVc6Mbbqw&e=" style="text-decoration:none" target="_blank">LLVM
Project Blog: LLDB is Coming to Windows</a></div>
<div id="m_7515340863614851877m_1763027943659039358LPMetadata_14703327535400.5399652255448155" style="margin:10px 0px 16px;color:rgb(102,102,102);font-weight:normal;font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;font-size:14px;line-height:14px">
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jqaYv5aDYHR_MGTz1rkWPg&m=cGDliRKtgFrgnkWwFqxPh4RyRVqdfaAmOCGP-zL_LbA&s=hwDLjBupq4WCB2Tnss4NgxIrkZa-YY8Haze1be8QP9w&e=" target="_blank">blog.llvm.org</a></div>
<div id="m_7515340863614851877m_1763027943659039358LPDescription_14703327535400.6174857090501791" style="display:block;color:rgb(102,102,102);font-weight:normal;font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;font-size:14px;line-height:20px;max-height:100px;overflow:hidden">
This preliminary bootstraping work is mostly complete, and you can use LLDB to debug simple executables generated with Clang on Windows today.</div>
</td>
</tr>
</tbody>
</table>
</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://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=jqaYv5aDYHR_MGTz1rkWPg&m=cGDliRKtgFrgnkWwFqxPh4RyRVqdfaAmOCGP-zL_LbA&s=ccEqO276ezHKkpCSnkWigGOXNEbBItPhrrolj22Dr3Y&e=" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>