[lldb-dev] RFC: Moving debug info parsing out of process

[via lldb-dev]

I'm aware that GSYM doesn't have full info, but if you're both looking at symbol-server kinds of mechanics and protocols, it would be silly to separate them into Clayborg-servers and Zach-servers just because GSYM cares mainly about line info.
But whatever.  You guys are designing this, go for it.
--paulr

From: Zachary Turner [mailto:zturner at google.com]
Sent: Wednesday, February 27, 2019 10:13 AM
To: Robinson, Paul
Cc: friss at apple.com; lldb-dev at lists.llvm.org
Subject: Re: [lldb-dev] RFC: Moving debug info parsing out of process

GSYM, as I understand it, is basically just an evolution of Breakpad symbols.  It doesn't contain full fidelity debug information (type information, function parameters, etc).
On Tue, Feb 26, 2019 at 5:56 PM <paul.robinson at sony.com<mailto:paul.robinson at sony.com>> wrote:
When I see this "parsing DWARF and turning it into something else" it is very reminiscent of what clayborg is trying to do with GSYM.  You're both talking about leveraging LLVM's parser, which is great, but I have to wonder if there isn't more commonality being left on the table.  Just throwing that thought out there; I don't have anything specific to suggest.
--paulr

From: lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org<mailto:lldb-dev-bounces at lists.llvm.org>] On Behalf Of Frédéric Riss via lldb-dev
Sent: Tuesday, February 26, 2019 5:40 PM
To: Zachary Turner
Cc: LLDB
Subject: Re: [lldb-dev] RFC: Moving debug info parsing out of process



On Feb 26, 2019, at 4:52 PM, Zachary Turner <zturner at google.com<mailto:zturner at google.com>> wrote:


On Tue, Feb 26, 2019 at 4:49 PM Frédéric Riss <friss at apple.com<mailto:friss at apple.com>> wrote:

On Feb 26, 2019, at 4:03 PM, Zachary Turner <zturner at google.com<mailto:zturner at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190228/f558aa85/attachment-0001.html>