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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
