[lldb-dev] RFC: Replacing all PDB code with non-Windows specific implementation

[Zachary Turner via lldb-dev]

To clarify, #1 is saying to re-implement the API **in LLVM** so that LLDB
transparently just works with no code changes.  While #2 is saying to
re-implement the plugin **in LLDB** to not use that API at all, and instead
use the low-level API that parses records directly from the file.

On Tue, Oct 2, 2018 at 1:57 PM Zachary Turner <zturner at google.com> wrote:

> Currently our PDBASTParser and SymbolFilePDB can only work on Windows
> because it relies on a builtin Windows library.
>
> In LLVM now we have full ability to read, parse, and interpret the
> contents of PDB files at the byte level.  There are two approaches to
> getting this working in LLDB.
>
> 1) Re-implement all the APIs that LLDB is currently using in terms of
> LLVM's native PDB parsing code.  This would be the most transparent
> solution from LLDB's point of view.
>
> 2) Re-implement the code in LLDB in terms of LLVM's low level PDB API.
>
> Originally there was someone working on #1, but I'm having second thoughts
> about whether that is the best approach.  The API in question has a log of
> "architecture overhead" associated with it, both in terms of runtime cost
> and implementation cost.  It essentially aims to be a one-size-fits-all
> abstraction over every possible use case for consuming debug info.  So in
> order to implement #1 you end up doing a lot of work that isn't strictly
> necessary for LLDB's use case.  Mechanical code only necessary to fit with
> the design.
>
> But LLDB doesn't exactly need all of that.  So I started thinking about
> #2.  Instead of spending weeks / months completing this API, then finding
> all the places where the APIs differ semantically in subtle ways that
> require changing the user code, we can just get rid of the existing
> implementation and re-implement existing functionality in terms of the low
> level PDB functionality of LLVM.
>
> Obviously, until it's at parity with the existing Windows-only
> implementation, this would be done side-by-side so the existing
> implementation would stay and still be the default.  We could putt he new
> implementation behind an environment variable or something for testing
> purposes (and use it unconditionally on non-Windows).
>
>
> I'm going to experiment with this by implementing a SymbolFilePDBNative
> plugin, but I want to see if anyone has strong objections to this approach.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20181002/f2cb3692/attachment.html>