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

[Sanimir Agovic via lldb-dev]

Hi Zachary,

On Mon, Feb 25, 2019 at 7:23 PM Zachary Turner via lldb-dev <
lldb-dev at 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 at 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 at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190227/a20e0b2d/attachment.html>