On Tue, Feb 26, 2019 at 4:49 PM Frédéric Riss <fr...@apple.com> wrote:
> > On Feb 26, 2019, at 4:03 PM, Zachary Turner <ztur...@google.com> wrote: > > 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. > > > That’s quite an ambitious goal. > > 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. > 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 > > 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. > > 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). > > > (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) > > 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. > 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. >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
