https://bugs.llvm.org/show_bug.cgi?id=41675

            Bug ID: 41675
           Summary: [DebugInfo@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: unassignedb...@nondot.org
          Reporter: jeremy.morse.l...@gmail.com
                CC: apra...@apple.com, chackz0...@gmail.com,
                    greg.bedw...@sony.com, llvm-bugs@lists.llvm.org,
                    orlando.hy...@sony.com, paul.robin...@am.sony.com,
                    stephen.to...@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to