[lldb-dev] RFC: Replacing all PDB code with non-Windows specific implementation
Zachary Turner via lldb-dev
lldb-dev at lists.llvm.org
Tue Oct 2 13:57:54 PDT 2018
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/533f1426/attachment.html>
More information about the lldb-dev
mailing list