labath requested changes to this revision. labath added a comment. This revision now requires changes to proceed.
In D116195#3208476 <https://reviews.llvm.org/D116195#3208476>, @zequanwu wrote: > In D116195#3207672 <https://reviews.llvm.org/D116195#3207672>, @labath wrote: > >> How are you planning to make use of this functionality? >> >> I'm asking because I'm wondering if it wouldn't be better to do this kind of >> processing in the PDB code, and then hand this class a finished list of line >> entries. Inserting entries into the middle of a vector is expensive, which >> is why our dwarf code no longer uses this function (it uses the >> vector<LineSequence> constructor instead). If we could get pdb to do >> something similar, then we could get rid of this function altogether. > > My plan was to insert entries when parsing inlined call site(`S_INLINESITE `) > in ParseBlocksRecursive, which usually happens after ParseLineTable. In PDB, > line entries in inlined call site often have same file addresses as line > entries in line table, and the former is better since it describes lines > inside inlined function rather than lines in caller. And we could have nested > inlined call sites. The line entries from inner call sites would always > overwrite the line entries from the outer call sites if they have the same > file address. So, I'm afraid that won't work. You shouldn't be modifying the line tables after ParseLineTable returns. Lldb (currently) considers the line tables to be either fully parsed or not parsed at all. There's no way to "partially" parse a line table. Attempting to do so will result in various strange effects, including file+line breakpoints resolving differently depending on which blocks have been parsed. I think you'll need to decide whether you want the inline info to be reflected in the line table or not. If yes, then you'll need to parse it from within ParseLineTable, at which point, you can probably do the deduplication outside of the LineTable class -- we can talk about how to make that easier. We can also try to come up with a completely different way to represent line tables in lldb. The currently implementation is clearly dwarf-centric, and probably not best suited for the pdb use case. But (due to the breakpoint use case) I don't think we can avoid having a mode which does a complete parse of whatever we consider to be a line table. The only thing we can do is to avoid parsing everything for the case where that is not necessary. > Maybe it's better to use a set to store the line entries, ordering just by > the file address so that insertion is cheaper? Currently, it compares other > fields if two lines have same file address > (https://github.com/llvm/llvm-project/blob/main/lldb/source/Symbol/LineTable.cpp#L150). > Is it necessary? I think line entries in line table always have distinct > file address. Given the above, I think that a sorted vector is an optimal data structure for the current state of the world. It's possible we don't need to sort by the other fields, but I don't think that's the biggest issue right now. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D116195/new/ https://reviews.llvm.org/D116195 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
