[Lldb-commits] [PATCH] D116195: [LLDB] Allows overwriting the existing line entry at given file address when inserting

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

In D116195#3211906 <https://reviews.llvm.org/D116195#3211906>, @zequanwu wrote:

> In D116195#3211346 <https://reviews.llvm.org/D116195#3211346>, @labath wrote:
>
>> 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.
>
> I think the inline info should be reflected in the line table. Otherwise `image lookup -a ...` cannot correctly show the file and line info for inlined functions. My plan is to keep a sorted (by address) set of line entries before adding into line sequence. Every time we add a new line entry into the set while parsing inline info, replace the existing entry with new entry if they have same address.

Line tables in LLDB are currently encoded such that they only need the deepest line table entry for a given address. Line tables in DWARF encode only these line table entries. The inlined call stack is decoded by looking at the lldb_private::Block objects and looking at their inline information using:

  const InlineFunctionInfo *Block::GetInlinedFunctionInfo() const;

The inline function info has a "Declaration" object that describes the call site which is accessed via:

  Declaration &InlineFunctionInfo::GetCallSite();

A declarations a file + line + column. So maybe the best thing to do would be to make sure that we only emit the deepest line table entries and possibly encode the call site info into the Block objects?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116195/new/

https://reviews.llvm.org/D116195