> On Feb 26, 2019, at 4:52 PM, Zachary Turner <ztur...@google.com> wrote: > > > > On Tue, Feb 26, 2019 at 4:49 PM Frédéric Riss <fr...@apple.com > <mailto:fr...@apple.com>> wrote: > >> On Feb 26, 2019, at 4:03 PM, Zachary Turner <ztur...@google.com >> <mailto: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
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. 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: - the server code - the client code that talks to the server - the current “local" code (for a pretty long while) Not ideal. I wish there was a way to factor at least the last 2. 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. Fred > >> 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
