[Lldb-commits] [PATCH] D39283: [lldb-dev] Update LLDB test cases for 'inlineStepping'

[Tamas Berghammer via Phabricator via lldb-commits]

tberghammer added a comment.

Hi Carlos,

Sorry for not responding to your related e-mails lately. I am still not convinced that tis is the right way forward as you are changing the expected behavior from LLDB side to make it work with the new debug info emitted by clang but I think the current behavior of LLDB is correct in this context. Both your reasoning and your compiler fix makes perfect sense for the case you mentioned in the commit message (I assume you missed a "inline_value += 1;" line from the C code snippet based on the assembly) but I am still concerned by the behavior in the original case with the following source code:

  void caller_trivial_1() {
      caller_trivial_2(); // In caller_trivial_1.
      inline_value += 1; 
  }

I think the following debug info is emitted in 32bit mode after your change:

- debug_info: caller_trivial_1 starts at 0x4000
- debug_line: 0x4000 belongs to line X (declaration of caller_trivial_1) and it is prologue
- debug_info: inlined caller_trivial_2 starts at 0x4010
- debug_line: 0x4020 belongs to line Y (first line of function caller_trivial_1) and it is not prologue
- debug_info: inlined caller_trivial_2 ends at 0x4080

When we step into caller_trivial_1 lldb will step to the first non-prologue line entry after the start of f what will be at 0x4020 and when we stop there that address is within g so lldb displays that we are stopped in caller_trivial_2.

I think the correct debug info would be the following:

- debug_info: caller_trivial_1 starts at 0x4000
- debug_line: 0x4000 belongs to line X (declaration of caller_trivial_1) and it is prologue
- debug_line: 0x4010 belongs to line Y (first line of function caller_trivial_1) and it is not prologue
- debug_info: inlined caller_trivial_2 starts at 0x4010
- debug_line: 0x4020 belongs to line Y (first line of function caller_trivial_2) and it is not prologue
- debug_info: inlined caller_trivial_2 ends at 0x4080

**In case of non-optimized build (it is true for the test) I would expect from a compiler that no line entry pointing to a line inside caller_trivial_1 will have an address what is inside the address range of any other function inlined into caller_trivial_2. I think this held before your change but not after.** Can you and others comment on this last expectation? If we agree that this expectation should hold then I think changing the test is the wrong and instead we should either change the line entry or the inlined function range writing code to produce debug info satisfying it.


https://reviews.llvm.org/D39283