<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 29, 2015, at 11:08 AM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">Does this make sense?<br class=""></div></div></div></blockquote><div><br class=""></div><div>Sure, no objection to moving files around :-)</div><div><br class=""></div><div>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).</div><div><br class=""></div><div>Fred</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_quote">On Thu Jan 29 2015 at 10:54:37 AM Frédéric Riss <<a href="mailto:friss@apple.com" class="">friss@apple.com</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2015, at 10:20 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank" class="">zturner@google.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">so you would have libDebugInfoDWARF and libDebugInfoPDB. Would you still have libDebugInfo at all?</div><div class=""><br class=""></div><div class="">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.</div></div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">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:</div><div class=""><br class=""></div><div class="">1) Not every consumer of DebugInfo wants both types of DebugInfo.</div><div class="">2) The pdb reading code relies <b class="">very heavily</b> 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thoughts? Comments? Suggestions?</div><div class="">Zach</div></div>
</div></blockquote></div></div></blockquote></div></div></div>
</div></blockquote></div><br class=""></body></html>