clayborg added a comment. So in the actual line table parsing code it seems like we are creating a line table in LLVM format, complete with sequences and a bunch of LLVM data structures, and then copying the results over into LLDB and then throwing away the LLVM line table. It would be nicer to modify the LLVM line table code to be able to get a callback when a row was pushed (if it isn't already in that format) and expose that so clients, like LLDB, can just get a callback and only store the data structure we care about. This would allow us to share the llvm line table parsing code and re-use it in LLDB, but not require twice the memory and overhead. Symbolication tools could also take advantage of this by not storing any rows except the closest matching row.
================ Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:201 + original_file)) + continue; + ---------------- I am worried about this continue stuff. If this fails, all of our file indexes will be off and nothing will make sense. We need the indexes in the support files to match those in the prologue. ================ Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:208 + remapped_file)) + continue; + ---------------- Ditto ================ Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:211 + module->RemapSourceFile(llvm::StringRef(original_file), remapped_file); + support_files.Append(FileSpec(remapped_file)); + } ---------------- Is this FileSpec constructor going to do the right thing for all path types (windows, linux, etc)? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62570/new/ https://reviews.llvm.org/D62570 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
