[llvm-bugs] [Bug 41675] New: [DebugInfo at O2] Too much indirection added to stack pointer's variable location
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Apr 30 09:33:42 PDT 2019
https://bugs.llvm.org/show_bug.cgi?id=41675
Bug ID: 41675
Summary: [DebugInfo at O2] Too much indirection added to stack
pointer's variable location
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Keywords: wrong-debug
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedbugs at nondot.org
Reporter: jeremy.morse.llvm at gmail.com
CC: aprantl at apple.com, chackz0x12 at gmail.com,
greg.bedwell at sony.com, llvm-bugs at lists.llvm.org,
orlando.hyams at sony.com, paul.robinson at am.sony.com,
stephen.tozer at sony.com
Blocks: 38768
Spinning out of bug 41534, where Yuanbo has the following code:
--------8<--------
$ cat abc.c
int a;
int *b;
int main() {
int l_1081 = 1834104526;
int *c = &l_1081;
b = c;
*b = a = 9;
optimize_me_not();
}
$ cat outer.c
optimize_me_not() {}
-------->8--------
Compiling with clang/llvm r358073 and options "-O2 -g", printing the "c"
variable on any line of the program yields a pointer that doesn't point at the
stack. Examining the location:
--------8<--------
DW_AT_location (0x00000000
[0x0000000000400486, 0x00000000004004a9): DW_OP_breg7 RSP+4)
DW_AT_name ("c")
-------->8--------
Shows that the location of 'c' has grown one too many levels of indirection:
the variable should be the _value_ of RSP+4 (i.e., a pointer at the stack), not
the memory data that the expression points at.
Examining the debug intrinsics for the "c" variable as they change over time,
before isel we have:
dbg.value(metadata i32* %l_1081, metadata !19, metadata !DIExpression())
Between isel and prologepilog, where frame indexes are finalised, we get:
DBG_VALUE %stack.0.l_1081, $noreg, !19, !DIExpression(), [...]
And from prologepilog to object emission we get:
DBG_VALUE $rsp, $noreg, !19, !DIExpression(DW_OP_plus_uconst, 4), [...]
My current belief is that switching the DIExpression from being empty to
non-empty also implicitly transforms the DBG_VALUE into being a memory location
description rather than a register location description. However, I'm
unfamiliar with how the DWARF backend treats these things, I'm about 70%
confident.
Adding a DW_OP_stack_value to non-indirect DBG_VALUEs when frameindexes are
rewritten fixes this example but makes a bunch of tests break, in seemly
significant ways. I haven't dug any further, it might be that DW_OP_stack_value
is only needed when the DIExpression is initially empty?
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=38768
[Bug 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190430/d432eed8/attachment-0001.html>
More information about the llvm-bugs
mailing list