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? 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/81e39099/attachment.html>
> 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 <mailto:friss at apple.com>> wrote: >> On Jan 29, 2015, at 10:20 AM, Zachary Turner <zturner at google.com <mailto: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/6493c724/attachment.html>
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>