<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 26, 2019, at 4:52 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><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" class="">friss@apple.com</a>> wrote:<br class=""></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" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Feb 26, 2019, at 4:03 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank" class="">zturner@google.com</a>> wrote:</div><br class="m_5473038149496595420Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""><br class=""></div></div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class="">That’s quite an ambitious goal.</div><div class=""><br class=""></div><div class="">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 class="">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></div></blockquote><div><br class=""></div><div>This seems fairly easy for Function or symbols in general, as it’s easy to abstract their few properties, but as soon as you get to the type system, I get worried.</div><div><br class=""></div><div>Your representation needs to have the full expressivity of the underlying debug info format. Inventing something new in that space seems really expensive. For example, every piece of information we add to the debug info in the compiler would need to be handled in multiple places:</div><div> - the server code</div><div> - the client code that talks to the server</div><div> - the current “local" code (for a pretty long while)</div><div>Not ideal. I wish there was a way to factor at least the last 2. </div><div><br class=""></div><div>But maybe I’m misunderstanding exactly what you’d put in your JSON. If it’s very close to the debug format (basically a JSON representation of the DWARF or the PDB), then it becomes more tractable as the client code can be the same as the current local one with some refactoring.</div><div><br class=""></div><div>Fred</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><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" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div></div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class="">(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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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" class=""><div class=""><blockquote type="cite" class=""><div class="">
</div></blockquote></div></div></blockquote></div></div>
</div></blockquote></div><br class=""></body></html>