
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 Nov 28, 2017, at 6:49 AM, Daniel Olivier via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;" class=""><div class="">Hi.</div><div class=""><br class=""></div><div class="">My goal is to process symbol files (i.e. PE-COFF/PDB, ELF/DWARF), and so I sought to examine how this is done in lldb. However, without first studying the code for an unreasonable amount of time, I just want to ask this simple question.</div><div class=""><br class=""></div><div class="">Consider the header files that pertain to symbol files in llvm (i.e. $LLVM_ROOT/include/llvm/DebugInfo) and lldb (i.e. $LLVM_ROOT/tools/lldb/source/Plugins/SymbolFile/).</div><div class=""><br class=""></div><div class="">For PDB support, I see only two classes (.cpp/.h file pairs, in $LLDB_ROOT/source/Plugins/SymbolFile/PDB), PDBASTParser and SymbolFilePDB, which appear to leverage the LLVM PDB implementation, and act as a facade to the LLVM implementation. This pattern doesn't repeat in the case of the DWARF format, where the file and class hierarchy appears duplicated, and yet are also quite different. </div><div class=""><br class=""></div><div class="">Its hard to describe the differences and similarities I see between the DWARF files, but so far, I can only guess that the differences are historical (forked and never re-merged), and that lldb only ever needed to read these files (the base LLVM implementation being more complete, in order to be able to generate them in the first place and merge or manipulate them once they are created).</div></div></div></blockquote></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;" class=""><div class="">Can anyone briefly explain the architectural choices made here?</div></div></div></blockquote><br class=""></div><div><div>LLMV's DWARF parser was born as a copy of the LLDB DWARF parser at the time and the person that did the port never attempted to switch LLDB to using the LLVM version as the only reason he added it was to be able to extract line table information. The LLMV DWARF parser has grown a lot over the years. Someone could take the time to switch LLDB over to use the LLVM DWARF parser, but that is a lot of work that will likely introduce bugs in the short term, though this would be valuable to do. I worked on the LLMV DWARF parser in an effort to make that happen last year, so the LLVM DWARF parser has everything that LLDB needs in order to switch, except someone that has the time to do this work.</div><div class=""><br class=""></div></div><div>LLDB provides an object file (ELF, COFF, MACHO) and debug info (DWARF, PDB) agnostic representation of debug info that can represent everything in these files. We have plugins for DWARF and PDB that convert those formats into the LLDB format. We do so lazily by parsing only what we need when we need it. Another step that the symbol file plug-ins in LLDB do is to convert any types in the debug info into clang::ASTContext types so we can use clang to run expressions on the debug info which has been converted back into clang AST types.</div><div><br class=""></div><div>So if you are looking to process symbol files, you could just use LLDB (LLDB.framework on Mac or liblldb.so on other systems). We have a public API that is stable and that entire API is available through python in case you need to script any solutions. </div><div><br class=""></div><div>Can you elaborate on what you are wanting to do with your parsing of the object/debug info files?</div><div><br class=""></div><div>Greg</div><div><br class=""></div><br class=""></body></html>