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. 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/04027ea9/attachment.html>
On Thu Jan 29 2015 at 10:22:17 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. > > 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? >Sounds good. Naming bikeshed: DWARF/Dwarf and PDB as directory names. Might want to ask Frederic about any pending patches he wants to get in before you move things around under him. git _should_ deal with it, but... -eric> Zach > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150129/d41bae94/attachment.html>
> On Jan 29, 2015, at 10:24 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Thu Jan 29 2015 at 10:22:17 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. > > 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? > > Sounds good. Naming bikeshed: >Sounds generally good. Not knowing much about PDB; are there any plans to have some kind of unified interface between dwarf and pdb (don’t know if that makes sense), or will they be kept separate?> DWARF/Dwarf and PDB as directory names.The official spelling is DWARF but it’s visually heavy and doesn’t play well with camelcase identifiers. DWARF when it’s used alone and Dwarf when it’s part of a longer word? -- adrian> > Might want to ask Frederic about any pending patches he wants to get in before you move things around under him. git _should_ deal with it, but... > > -eric > > Zach > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150129/cec8d0db/attachment.html>
>The pdb reading code relies *very heavily* on Windows APIscan you make shure not to have any windows api stuff in the pdb-reader interface so its easy to - if someone wants to - implement an windows-api independent version (support reading under linux etc.) because the pdb format needs to be analysed anyway for writing pdb information on compile/link (in the future) Am 29.01.2015 um 19:20 schrieb Zachary Turner:> 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. > > 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 > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 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/2f796964/attachment.html>
> On Jan 29, 2015, at 10:24 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Thu Jan 29 2015 at 10:22:17 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. > > 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? > > Sounds good. Naming bikeshed: > > DWARF/Dwarf and PDB as directory names. > > Might want to ask Frederic about any pending patches he wants to get in before you move things around under him. git _should_ deal with it, but…I have the DWARFExpression review in flight that it might be nice to land before the move (although as you say git should handle it). For the things I have out of tree I’ll just deal with it. Fred> -eric > > Zach > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150129/ddfa270a/attachment.html>
If you mean just the interface, then yes I can an effort to make sure the interface doesn't expose anything Windows-specific. This particular implementation will obviously need to use Windows specific things though. On Thu Jan 29 2015 at 11:00:38 AM Dennis Luehring <dl.soluz at gmx.net> wrote:> >The pdb reading code relies *very heavily* on Windows APIs > > can you make shure not to have any windows api stuff in the pdb-reader > interface > so its easy to - if someone wants to - implement an windows-api > independent version (support reading under linux etc.) > because the pdb format needs to be analysed anyway for writing pdb > information on compile/link (in the future) > > > Am 29.01.2015 um 19:20 schrieb Zachary Turner: > > 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. > > > > 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 > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150129/fc5e87e7/attachment.html>
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>