[llvm-bugs] [Bug 28458] New: [codeview] properly emit scope for variables

[via llvm-bugs]

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

            Bug ID: 28458
           Summary: [codeview] properly emit scope for variables
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: vladimir at pobox.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

When compiling something like:

int somefunc(int arg) {
  {
     char scopedChar = 0;
     scopedChar++;
  }

  int n = 0;
  for (int number = 0; number < 5; number++) {
    n += number;
  }
  for (int number = 0; number < 5; number++) {
    n += number;
  }
  return n;
}

the VS debugger shows two entries in the "Locals" view for "number", showing
them and "scopedChar" as "Variable is optimized away and not available." at the
entrance to the function.  Stepping through it, "scopedChar" becomes available,
and then when it leaves scope it sticks around in the locals view.  Same with
the two "number" variables.

When compiled with MSVC, the list of locals properly changes based on what's
actually in scope.  The same behaviour is in windbg, with "tv" (show locals).

With readobj, MSVC generates codeview entries that look like this:

    BlockStart {
      PtrParent: 0x0
      PtrEnd: 0x0
      CodeSize: 0x2D
      CodeOffset: ?somefunc@@YAHH at Z+0x1D
      Segment: 0x0
      BlockName:
      LinkageName: ?somefunc@@YAHH at Z
    }
    RegRelativeSym {
      Offset: 0x8
      Type: int (0x74)
      Register: 0x14F
      VarName: number
    }
    BlockEnd {
    }
[similar for the second one, just with a different CodeOffset]

Whereas clang/llvm generates:

    Local {
      Type: int (0x74)
      Flags [ (0x0)
      ]
      VarName: number
    }
    DefRangeRegisterRel {
      BaseRegister: 335
      HasSpilledUDTMember: No
      OffsetInParent: 0
      BasePointerOffset: 8
      LocalVariableAddrRange {
        OffsetStart: .text+0x1F
        ISectStart: 0x0
        Range: 0x2F
      }
    }
[similar for second, with different OffsetStart]

The IR for these looks like:

!21 = !DILocalVariable(name: "number", scope: !22, file: !1, line: 9, type:
!10)
!22 = distinct !DILexicalBlock(scope: !7, file: !1, line: 9, column: 3)
...
!37 = !DILocalVariable(name: "number", scope: !38, file: !1, line: 12, type:
!10)
!38 = distinct !DILexicalBlock(scope: !7, file: !1, line: 12, column: 3)

It looks like the debuggers (sort of) understand the RangeRegisterRel as a
proper scope for when the local variable is valid, but don't actually limit
visibility to that scope.  Should llvm be generating BlockStart/BlockEnd in CV
for all DILexicalBlocks?

-- 
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/20160707/dcc22a8f/attachment.html>