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.robin...@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-boun...@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 <ztur...@google.com> wrote: > > > > > > 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 > > > > 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
