[llvm-bugs] [Bug 41600] New: [DebugInfo at O2] DbgEntityHistoryCalculator allows stack-slot variable locations to leak between blocks

[via llvm-bugs]

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

            Bug ID: 41600
           Summary: [DebugInfo at O2] DbgEntityHistoryCalculator allows
                    stack-slot variable locations to leak between blocks
           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, bjorn.a.pettersson at ericsson.com,
                    chackz0x12 at gmail.com, david.stenberg at ericsson.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

DbgEntityHistoryCalculator currently appears to allow stack-slot-referencing
debug variable locations to fall through into blocks where they are no longer
valid. The IR at the bottom of this ticket replicates this scenario, when run
with "llc input.ll -O0 -o out.o -filetype=obj -mtriple=x86_64--" (I'm using
LLVM r358073).

Examine the output object file disassembly and the location list for the "bees"
variable. I get:

-------->8--------
                  DW_AT_location        (0x00000000
                     [0x000000000000000d,  0x000000000000001f): DW_OP_breg7
RSP-4
                     [0x000000000000001f,  0x000000000000002c): DW_OP_lit1,
DW_OP_stack_value
                     [0x000000000000002c,  0x0000000000000042): DW_OP_lit2,
DW_OP_stack_value)
--------8<--------

Which is roughly the right thing, as the IR states the variable lies first on
the stack, and then it has constant values. However, looking at the
disassembly, the range of the RSP-4 entry covers both the "entry" IR block and
the "bb1" IR block. It should not cover the "bb1" block because there are no
paths to that block where the variable location is not redefined. If one adds
-stop-after=livedebugvalues to the command line, we see that the bb1 block
correctly does not have a DBG_VALUE in it at all, because livedebugvalues can't
guarantee the variable location in that block. It would appear that
DbgEntityHistoryCalculator then allows the DBG_VALUE in the entry block to leak
into bb1.

Having just frobbed this for D59431, the problem seems to be that while we can
identify the open debug range as being something we should close, we then don't
because the ChangingRegs set in DbgEntityHistoryCalculator indicates that
things referring to unchanging registers (i.e. the stack pointer) should never
be clobbered. It's not clear why this is, and removing that facility makes
tests fail; I haven't dug any further.

-------->8--------
declare void @llvm.dbg.value(metadata, metadata, metadata)
declare void @llvm.dbg.addr(metadata, metadata, metadata)

define dso_local i32 @foo(i1 %cond, i32 %input) !dbg !5 {
entry:
  %something = alloca i32
  store i32 0, i32* %something
  call void @llvm.dbg.addr(metadata i32 *%something, metadata !1, metadata
!DIExpression()), !dbg !6
  br i1 %cond, label %truebr, label %falsebr

bb1:
  %value = phi i32 [ %value1, %truebr ], [ %value2, %falsebr ]
  br label %exit, !dbg !6

truebr:
  call void @llvm.dbg.value(metadata i32 1, metadata !1, metadata
!DIExpression()), !dbg !6
  %value1 = add i32 %input, 1
  br label %bb1

falsebr:
  call void @llvm.dbg.value(metadata i32 2, metadata !1, metadata
!DIExpression()), !dbg !6
  %value2 = add i32 %input, 2
  br label %bb1

exit:
  %wat = load i32, i32 *%something
  %nou = add i32 %wat, %value
  ret i32 %nou, !dbg !6
}

!llvm.module.flags = !{!4}
!llvm.dbg.cu = !{!2}
!1 = !DILocalVariable(name: "bees", scope: !5, type: !7)
!2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !3, producer:
"beards", isOptimized: true, runtimeVersion: 4, emissionKind: FullDebug)
!3 = !DIFile(filename: "bees.cpp", directory: "")
!4 = !{i32 2, !"Debug Info Version", i32 3}
!5 = distinct !DISubprogram(name: "nope", scope: !2, file: !3, line: 1, unit:
!2, type: !8)
!6 = !DILocation(line: 0, scope: !5)
!7 = !DIBasicType(name: "unsigned int", size: 32, encoding: DW_ATE_unsigned)
!8 = !DISubroutineType(types: !9)
!9 = !{!7, !7, !7}
--------8<--------

-- 
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/20190425/02062eae/attachment.html>