[llvm-bugs] [Bug 36579] New: LiveDebugVariables removes all DBG_VALUE undef, ...

[via llvm-bugs]

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

            Bug ID: 36579
           Summary: LiveDebugVariables removes all DBG_VALUE undef, ...
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: aprantl at apple.com
                CC: llvm-bugs at lists.llvm.org

Via https://reviews.llvm.org/D43956#1025531, found by Björn Pettersson!

But maybe it is a bug that LiveDebugVariables removes all DBG_VALUE undef, ...?

I think it is.

If you compile the function at -O1 (to force the constant to be described with
a dbg.value)

 void foo() {
   // single basic block
   int x = 42;
   bar();
   x = 23;
   bar();
 }


and replace the second dbg.value with a dbg.value(undef) in the LLVM IR and run
it through llc, do we get the range of the constant 42 correct in the resulting
location list for x? Does it end before the second call to bar()?


Nope, if I do that the DBG_VALUE is removed by LiveDebugVariables. And we no
longer get a .debug_loc range for "x". Instead we get

        .byte   3                       # Abbrev [3] 0x3f:0xc DW_TAG_variable
        .byte   42                      # DW_AT_const_value
        .long   .Linfo_string4          # DW_AT_name
        .byte   1                       # DW_AT_decl_file
        .byte   5                       # DW_AT_decl_line
        .long   76                      # DW_AT_type

So "x" will appear as being 42 throughout the function.


I think the right way forward would be to fix LiveDebugVariables to not drop
undef DBG_VALUEs. This will be slightly more expensive in terms of compile time
and size of the debug info (since we now need to use location lists for cases
like the one you found), but it will be far more accurate.

-- 
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/20180302/f32f98a8/attachment-0001.html>