Hi Zachary, On Mon, Feb 25, 2019 at 7:23 PM Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > [...] > Thoughts? Having a standalone symbols interface would open many tooling possibilities, the available interfaces are too dwarfish and too primitive. This necessarily does not require an out-of-process symbol server but I see that it is appealing to you especially with the problems you are facing.
I do not want start bikeshedding on implementation details already as it seems you have your own but I suggest starting with a linetable interface. It has a simple and stable interface addr2locs/loc2addrs, is complete on its own (no symbols required), not prone to dwarf/pdb or language oddities, and imho is the most fundamental debug information. This would allow you to focus on the necessary details and still have a good portion of functionality. Out-of-process symbol server do work but are less useful nowadays. Hope it solves the problems you are facing. -Sanimir On Mon, Feb 25, 2019 at 7:23 PM Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi all, > > We've got some internal efforts in progress, and one of those would > benefit from debug info parsing being out of process (independently of > whether or not the rest of LLDB is out of process). > > There's a couple of advantages to this, which I'll enumerate here: > > - It improves one source of instability in LLDB which has been known > to be problematic -- specifically, that debug info can be bad and handling > this can often be difficult and bring down the entire debug session. While > other efforts have been made to address stability by moving things out of > process, they have not been upstreamed, and even if they had I think we > would still want this anyway, for reasons that follow. > - It becomes theoretically possible to move debug info parsing not > just to another process, but to another machine entirely. In a broader > sense, this decouples the physical debug info location (and for that > matter, representation) from the debugger host. > - It becomes testable as an independent component, because you can > just send requests to it and dump the results and see if they make sense. > Currently there is almost zero test coverage of this aspect of LLDB apart > from what you can get after going through many levels of indirection via > spinning up a full debug session and doing things that indirectly result in > symbol queries. > > The big win here, at least from my point of view, is the second one. > Traditional symbol servers operate by copying entire symbol files (DSYM, > DWP, PDB) from some machine to the debugger host. These can be very large > -- we've seen 12+ GB in some cases -- which ranges from "slow bandwidth > hog" to "complete non-starter" depending on the debugger host and network. > In this kind of scenario, one could theoretically run the debug info > process on the same NAS, cloud, or whatever as the symbol server. Then, > rather than copying over an entire symbol file, it responds only to the > query you issued -- if you asked for a type, it just returns a packet > describing the type you requested. > > The API itself would be stateless (so that you could make queries for > multiple targets in any order) as well as asynchronous (so that responses > might arrive out of order). Blocking could be implemented in LLDB, but > having the server be asynchronous means multiple clients could connect to > the same server instance. This raises interesting possibilities. For > example, one can imagine thousands of developers connecting to an internal > symbol server on the network and being able to debug remote processes or > core dumps over slow network connections or on machines with very little > storage (e.g. chromebooks). > > > On the LLDB side, all of this is hidden behind the SymbolFile interface, > so most of LLDB doesn't have to change at all. While this is in > development, we could have SymbolFileRemote and keep the existing local > codepath the default, until such time that it's robust and complete enough > that we can switch the default. > > Thoughts? > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev