<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 26, 2019 at 4:49 PM Frédéric Riss <<a href="mailto:friss@apple.com">friss@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div>On Feb 26, 2019, at 4:03 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:</div><br class="m_5473038149496595420Apple-interchange-newline"><div><div dir="ltr">I would probably build the server by using mostly code from LLVM.  Since it would contain all of the low level debug info parsing libraries, i would expect that all knowledge of debug info (at least, in the form that compilers emit it in) could eventually be removed from LLDB entirely.</div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>That’s quite an ambitious goal.</div><div><br></div><div>I haven’t looked at the SymbolFile API, what do you expect the exchange currency between the server and LLDB to be? Serialized compiler ASTs? If that’s the case, it seems like you need a strong rev-lock between the server and the client. Which in turn add quite some complexity to the rollout of new versions of the debugger.</div></div></div></blockquote><div>Definitely not serialized ASTs, because you could be debugging some language other than C++.  Probably something more like JSON, where you parse the debug info and send back some JSON representation of the type / function / variable the user requested, which can almost be a direct mapping to LLDB's internal symbol hierarchy (e.g. the Function, Type, etc classes).  You'd still need to build the AST on the client</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div><div dir="ltr"><div>So, for example, all of the efforts to merge LLDB and LLVM's DWARF parsing libraries could happen by first implementing inside of LLVM whatever functionality is missing, and then using that from within the server.  And yes, I would expect lldb to spin up a server, just as it does with lldb-server today if you try to debug something.  It finds the lldb-server binary and runs it.</div><div><br></div><div>When I say "switching the default", what I mean is that if someday this hypothetical server supports everything that the current in-process parsing codepath supports, we could just delete that entire codepath and switch everything to the out of process server, even if that server were running on the same physical machine as the debugger client (which would be functionally equivalent to what we have today).</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>(I obviously knew what you meant by "switching the default”, I was trying to ask about how… to which the answer is by spinning up a local server)</div><div><br></div><div>Do you envision LLDB being able to talk to more than one server at the same time? It seems like this could be useful to debug a local build while still having access to debug symbols for your dependencies that have their symbols in a central repository.</div></div></div></blockquote><div><br></div><div>I hadn't really thought of this, but it certainly seems possible.  Since the API is stateless, it could send requests to any server it wanted, with some mechanism of selecting between them.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div>
</div></blockquote></div></div></blockquote></div></div>