<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 2, 2018 at 1:57 PM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Currently our PDBASTParser and SymbolFilePDB can only work on Windows because it relies on a builtin Windows library.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>2) Re-implement the code in LLDB in terms of LLVM's low level PDB API.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div><br></div><div>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.<br></div></div>
</blockquote></div>