[LLVMdev] Adding PDB support to lib\DebugInfo

[Zachary Turner]

In theory it probably could go into LLDB, but when we discussed this
internally, we just decided that debug info goes in llvm on pure principle
and for consistency. I also agree it would be nice for LLDB to use LLVM
dwarf parser, but this needs some evangelism in the LLDB community before
it can happen :)

There are potential use cases for PDB reading in llvm, for example
llvm-symbolizer and ASAN, who i think have hand rolled PDB support, so
there's definitely some merit to providing this kind of thing at the LLVM
level, but that's more of a long term thing.
On Thu, Jan 29, 2015 at 11:52 AM Frédéric Riss <friss at apple.com> wrote:

> On Jan 29, 2015, at 11:08 AM, Zachary Turner <zturner at google.com> wrote:
>
> See my earlier response to Adrian.  But I'll rehash the point here, which
> is that basically in the short term, I think it makes the most sense to
> keep them separate.  In the future, if / when we decide to provide a
> unified interface (e.g libDebugInfo as you suggest), there will be
> additional machinery required to wrap the two interfaces, so we could move
> the DIContext class at that time.
>
> Does this make sense?
>
>
> Sure, no objection to moving files around :-)
>
> Out of curiosity, if the only target users of the library are the dump
> tool and lldb, why put the code in LLVM and not only in LLDB? I would love
> to see LLDB using our Dwarf parser because there is quite some code
> duplication here, but it wouldn’t be the case for PDB support (again, not
> an objection, just a candide question).
>
> Fred
>
> On Thu Jan 29 2015 at 10:54:37 AM Frédéric Riss <friss at apple.com> wrote:
>
>> On Jan 29, 2015, at 10:20 AM, Zachary Turner <zturner at google.com> wrote:
>>
>> I've been working on adding pdb reading support to llvm.  This started as
>> a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has
>> been checked in and currently has limited support for dumping pdb.
>>
>> There's still more to be done on the pdb dumping tool, but at this point
>> -- to reduce duplicated effort -- I think it makes the most sense to start
>> moving some of this logic into a library in llvm, and then change
>> llvm-pdbdump to use the library.  Later, once the library is more
>> comprehensive, I plan to then use it in LLDB for reading PDBs while
>> debugging on Windows.
>>
>> I think the best way to do this is to move all of the code in
>> lib/DebugInfo to lib/DebugInfo/dwarf, and then make another folder called
>> lib/DebugInfo/pdb.   These would then be compiled into two separate
>> libraries.
>>
>>
>> so you would have libDebugInfoDWARF and libDebugInfoPDB. Would you still
>> have libDebugInfo at all?
>>
>> I ask because there is the DIContext abstraction that’s not tied to a
>> particular debug format (It’s used by llvm-symbolizer, and I guess you have
>> some interest in having that working on windows PDB files). But
>> DIContext.cpp as one method, thus having a library for just that might be
>> really overkill.
>>
>> Another approach is to just put the PDB code in the same folder as the
>> dwarf code, but I don't like this approach for a number of reasons:
>>
>> 1) Not every consumer of DebugInfo wants both types of DebugInfo.
>> 2) The pdb reading code relies *very heavily* on Windows APIs, and will
>> not compile on other platforms.  This is solvable with some CMake
>> machinery, but it's ugly and unwarranted in my opinion.
>>
>> So as a first step in this direction I'd like to propose moving the code
>> in lib/DebugInfo to lib/DebugInfo/dwarf, and then updating the rest of llvm
>> accordingly.
>>
>> Thoughts?  Comments?  Suggestions?
>> Zach
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150129/dcb8f1e8/attachment.html>