[llvm-bugs] [Bug 43373] New: Block is missing entry value DBG_VALUE

[via llvm-bugs]

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

            Bug ID: 43373
           Summary: Block is missing entry value DBG_VALUE
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: david.stenberg at ericsson.com
                CC: jdevlieghere at apple.com, keith.walker at arm.com,
                    llvm-bugs at lists.llvm.org,
                    paul_robinson at playstation.sony.com

Reproduced using r372374.

Compiling the following test case:

  extern void bar(int);
  extern void baz(void);

  int foo(int p) {
    if (p)
      bar(1);
    baz();
    return 0;
  }

using:

  clang -O1 -g -Xclang -femit-debug-entry-values

gives the following disassembled output:

  0000000000000000 foo:
         0: 50                                  pushq   %rax
         1: 85 ff                               testl   %edi, %edi
         3: 74 0a                               je      10 <foo+0xf>
         5: bf 01 00 00 00                      movl    $1, %edi
         a: e8 00 00 00 00                      callq   0 <foo+0xf>
         f: e8 00 00 00 00                      callq   0 <foo+0x14>
        14: 31 c0                               xorl    %eax, %eax
        16: 59                                  popq    %rcx
        17: c3                                  retq

and the following location list for the parameter:

  DW_AT_location        (0x00000000
    [0x0000000000000000,  0x000000000000000a): DW_OP_reg5 RDI
    [0x000000000000000a,  0x000000000000000f): DW_OP_GNU_entry_value(DW_OP_reg5
RDI), DW_OP_stack_value)

As seen, the entry value ends before the second call to foo (at 0xf). As the
parameter is not modified, I'd except entry value locations being present for
the rest of the function.

This is how it looks after LiveDebugValues:

  bb.0.entry:
    successors: %bb.2(0x30000000), %bb.1(0x50000000)
    liveins: $edi

    DBG_VALUE $edi, $noreg, !19, !DIExpression(), debug-location !20
    DBG_VALUE $edi, $noreg, !19, !DIExpression(), debug-location !20
    frame-setup PUSH64r undef $rax, implicit-def $rsp, implicit $rsp
    CFI_INSTRUCTION def_cfa_offset 16
    TEST32rr killed renamable $edi, renamable $edi, implicit-def $eflags,
debug-location !21
    JCC_1 %bb.2, 4, implicit $eflags, debug-location !23

  bb.1.if.then:
    successors: %bb.2(0x80000000)

    DBG_VALUE $edi, $noreg, !19, !DIExpression(), debug-location !20
    $edi = MOV32ri 1, debug-location !24
    DBG_VALUE $edi, $noreg, !19, !DIExpression(DW_OP_LLVM_entry_value, 1),
debug-location !20
    CALL64pcrel32 @bar, csr_64, implicit $rsp, implicit $ssp, implicit $edi,
implicit-def $rsp, implicit-def $ssp, debug-location !24

  bb.2.if.end:
    CALL64pcrel32 @baz, csr_64, implicit $rsp, implicit $ssp, implicit-def
$rsp, implicit-def $ssp, debug-location !25
    $eax = XOR32rr undef $eax, undef $eax, implicit-def dead $eflags,
debug-location !26
    $rcx = frame-destroy POP64r implicit-def $rsp, implicit $rsp,
debug-location !26
    CFI_INSTRUCTION def_cfa_offset 8, debug-location !26
    RETQ killed $eax, debug-location !26

It seems that an entry value DBG_VALUE is not propagated to bb.2.if.end?

-- 
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/20190920/9815574a/attachment-0001.html>