[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


            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:

$ cat abc.c
int a;
int *b;
int main() {
  int l_1081 = 1834104526;
  int *c = &l_1081;
  b = c;
  *b = a = 9;

$ cat outer.c
optimize_me_not() {}

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:

   DW_AT_location    (0x00000000
      [0x0000000000400486,  0x00000000004004a9): DW_OP_breg7 RSP+4)
   DW_AT_name        ("c")

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%

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:

[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