Debug Info: Add support for named constants

[aprantl]

Summary

DWARF defines DW_TAG_constant for "languages that have true named constants" (DWARF v5 section 4.1). This patch adds LLVM IR metadata and DWARF AsmPrinter support for this feature. The primary motivation behind this addition is for representing "let"-bindings in Swift, to communicate to the debugger that these may not be modified. It is very likely also useful for many other programming languages that have named constants.

rdar://problem/16042546

[dblaikie]

What's a "true named constant" as opposed to, say, C++ (or C's) "const int X = 3;" (well, I guess const int X could be defined by a runtime expression, - OK, what about "constexpr int X = 3;" then?)

But seems fine in any case (:

[vsk]

IIUC @jingham makes the argument here that DW_TAG_constant isn't appropriate for swift's 'let', and instead suggests attaching DW_AT_const_value to the DW_TAG_variable (which lldb seems to already understand). Wdyt of that as an alternative?

[dblaikie]

In D67563#1669828, @vsk wrote:

IIUC @jingham makes the argument here that DW_TAG_constant isn't appropriate for swift's 'let', and instead suggests attaching DW_AT_const_value to the DW_TAG_variable (which lldb seems to already understand). Wdyt of that as an alternative?

Yeah, sounds like "let" variables can be runtime values like const int in C (eg: "void f(int g) { const int h = g; ... }") - which, like Jim said, I don't think is what's meant by DWARF's "true constants" (though it'd be nice if DWARF were a bit more descriptive there).

That said, inversely - since Swift doesn't use DWARF tags to describe types, you don't have the option of describing these in the same way as "const" variables in C - because you can't put a DW_TAG_const_type around the type (yeah, that wouldn't quite match the source even if you could do it - but I think it'd be a pretty good analogy, really). So in that sense, I could see how using "DW_TAG_constant" might be a reasonable workaround - if not for the parameter issue. If you can have a "let" be a parameter, then that needs to be a DW_TAG_formal_parameter and can't be DW_TAG_constant (as Jim says) - so you'll need some other representation to cope with this anyway.

DW_AT_const_value probably isn't that representation, though - because that's for, even moreso (perhaps, only due to the ambiguity of DW_TAG_constant's specification) than DW_TAG_constant - DW_AT_const_value stores a compile-time, storage-less things which not all "let" values seem to be.

[aprantl]

Before creating this patch I had considered 4 options:

1. Use DW_TAG_constant + DW_AT_location
   • Con: DWARF spec doesn't actually explicitly allow combining these two.
   • Con: There is no way to apply this to a DW_TAG_formal_parameter or DW_TAG_member
2. Use DW_TAG_variable + DW_AT_const_value
   • Big con: The DWARF spec doesn't allow DWARF exprs or loclists in DW_AT_const_value
3. Use DW_TAG_const_type or DW_TAG_immutable_type
   • We do use a DW_AT_type to point to a stub type that holds the mangled name, so this would work.
   • Con: Semantically odd since the constness is a property of the variable not of the type.
   • Pro: also works with DW_TAG_formal_parameter and member types.
4. We can invent our own DW_AT_LLVM_let_binding (true)
   • Con: Seems fairly Swift-specific (for example Rust has let mut which is like Swift's var).
   • Pro: also works with DW_TAG_formal_parameter and member types.
   • Pro: since most bindings are let, this would be more space-efficient.

Note that the parameter issue isn't quite such a bug deal since all parameters in Swift are constant unless they are specifically marked as inout, in which case the inout does become part of the type.
I'm starting to think we really should do either (3) or (4). Are there any concerns about approach (4), perhaps with a more generic name of DW_AT_LLVM_immutable?

[aprantl]

Okay. Here is an alternative patch that implements a flag DW_AT_LLVM_constant. "The Swift Programming Language" calls let-bindings "constants" and constant seems to be a generic enough term to be generally useful.

[dblaikie]

Out of curiosity does swift have const in the type system like C and C++? (I guess so) - and what would be the difference between a normal (non-let) variable of a const type, versus a let variable of a non-const type?

[aprantl]

In D67563#1670183, @dblaikie wrote:

Out of curiosity does swift have const in the type system like C and C++? (I guess so) - and what would be the difference between a normal (non-let) variable of a const type, versus a let variable of a non-const type?

Swift does not have const in the type system. There are no real pointers in the language; the closest equivalent are probably constant struct members, such as:

struct MyStruct {
  let i_am_a_constant : Int = 42
  var i_am_mutable : String
}

[aprantl]

-> https://docs.swift.org/swift-book/ReferenceManual/Types.html

[dblaikie]

In D67563#1670224, @aprantl wrote:

In D67563#1670183, @dblaikie wrote:

Out of curiosity does swift have const in the type system like C and C++? (I guess so) - and what would be the difference between a normal (non-let) variable of a const type, versus a let variable of a non-const type?

Swift does not have const in the type system. There are no real pointers in the language; the closest equivalent are probably constant struct members, such as:

struct MyStruct {
  let i_am_a_constant : Int = 42
  var i_am_mutable : String
}

Would seem to me (with an obvious C++ bias in my view of the world) that it maps best to i_am_a_constant being a DW_TAG_variable (or function_parameter) with a DW_TAG_const_type that has a base type of "Int" (however that's represented).

But I realize that might not be a good fit for Swift/its debuggers, etc, and certainly tend to leave this up to whatever you folks want to do with your language. Just my 2c :)

[aprantl]

In D67563#1670226, @dblaikie wrote:

Would seem to me (with an obvious C++ bias in my view of the world) that it maps best to i_am_a_constant being a DW_TAG_variable (or function_parameter) with a DW_TAG_const_type that has a base type of "Int" (however that's represented).

But I realize that might not be a good fit for Swift/its debuggers, etc, and certainly tend to leave this up to whatever you folks want to do with your language. Just my 2c :)

It's not elegant in LLDB to peel the constness out of the type and attach it to the variable (the code that takes a DWARF type and returns a Swift type would need to ignore it and the code that builds an lldb_private::Variable needs to look into the DW_AT_type), but certainly doable, and implementation details of one specific debugger shouldn't really affect this decision. The prevalence of let-bindings may cause debug info to blow up a bit with all the extra DW_TAG_const_types, but that's not going to be a showstopper either.

[vsk]

FTR, I like this approach (introducing DW_AT_LLVM_constant). A side-benefit of not attaching AT_location to TAG_constant is that there's no need to update the dwarf location statistics code. So, +1/lgtm on my end -- would be great to have another +1 on this change though.

[aprantl]

After some consideration I concluded that this isn't the best approach either. [There's no plan to do that, but] If we ever want to serialize Swift types into DWARF then an attribute on (local) variables isn't enough to describe let-members of structs. So instead I'm currently preparing a patch (no LLVM involved) that will wrap let-bound types in DW_TAG_const_type (like the const qualifier in C).

[probinson]

In D67563#1669814, @dblaikie wrote:

What's a "true named constant" as opposed to, say, C++ (or C's) "const int X = 3;" (well, I guess const int X could be defined by a runtime expression, - OK, what about "constexpr int X = 3;" then?)

My take is, const and constexpr distinguish the set of possible uses of a variable; they don't turn the item into something that is not a variable. You can still take its address, for example. By that criterion, C and C++ don't have true named constants.

DW_TAG_constant is aimed more at other languages where constants are considered a different kind of language entity. The DWARF doc has examples from Fortran; I know Pascal and COBOL have them.

[dblaikie]

In D67563#1670227, @aprantl wrote:

In D67563#1670226, @dblaikie wrote:

Would seem to me (with an obvious C++ bias in my view of the world) that it maps best to i_am_a_constant being a DW_TAG_variable (or function_parameter) with a DW_TAG_const_type that has a base type of "Int" (however that's represented).

But I realize that might not be a good fit for Swift/its debuggers, etc, and certainly tend to leave this up to whatever you folks want to do with your language. Just my 2c :)

It's not elegant in LLDB to peel the constness out of the type and attach it to the variable (the code that takes a DWARF type and returns a Swift type would need to ignore it and the code that builds an lldb_private::Variable needs to look into the DW_AT_type), but certainly doable, and implementation details of one specific debugger shouldn't really affect this decision. The prevalence of let-bindings may cause debug info to blow up a bit with all the extra DW_TAG_const_types, but that's not going to be a showstopper either.

Fair - I don't have so much experience with those sort of languages so perhaps haven't ever dealt with the concept that's trying to be described here.

I wonder, then, about a "constexpr T&" - maybe that's closer to a "true constant" - you can't take its address? (references have no address, as far as the language is concerned - maybe not-even-constexpr T& is a "true constant" (but only allows "address constants" not other things like integers to have similar handling)).

& maybe 'let' is more like a const T than it is one of these "true constant" things? (sounds like that's where Adrian's going with it now anyway)

[aprantl]

Swift's let is indeed closer to C's const than to a named constant in Pascal (https://wiki.freepascal.org/Constants). The Swift language spec call them constants, and they are effectively SSA variables (with storage). But (and this is where it differs from Pascal constants) let bindings can also appear inside of composite types (there are let struct and class members) and as function arguments (unless a parameter is explicitly marked as inout, similar to Fortran). I have found that DW_TAG_const is the only mechanism that works for all of these use-cases.

[aprantl]

How do Fortran compilers represent regular versus inout arguments in DWARF?

[dblaikie]

In D67563#1675351, @aprantl wrote:

Swift's let is indeed closer to C's const than to a named constant in Pascal (https://wiki.freepascal.org/Constants). The Swift language spec call them constants, and they are effectively SSA variables (with storage). But (and this is where it differs from Pascal constants) let bindings can also appear inside of composite types (there are let struct and class members) and as function arguments (unless a parameter is explicitly marked as inout, similar to Fortran). I have found that DW_TAG_const is the only mechanism that works for all of these use-cases.

Adding an attribute for "I'm a 'let'" to DW_TAG_variable, DW_TAG_formal_parameter and DW_TAG_member I don't think would've been the end of the world/worst thing, but DW_TAG_const does seem like a closer general model as far as DWARF is concerned, yeah.

[aprantl]

In D67563#1675356, @aprantl wrote:

How do Fortran compilers represent regular versus inout arguments in DWARF?

According to godbolt.org, gfortran 8.2 emits the same DWARF for in and inout parameters. That doesn't help :-)

[probinson]

In D67563#1675264, @dblaikie wrote:

I wonder, then, about a "constexpr T&" - maybe that's closer to a "true constant" - you can't take its address? (references have no address, as far as the language is concerned - maybe not-even-constexpr T& is a "true constant" (but only allows "address constants" not other things like integers to have similar handling)).

I admire your gaming my off-the-cuff example. But no sensible producer would try to coerce that into a DW_TAG_constant.

In D67563#1675356, @aprantl wrote:

How do Fortran compilers represent regular versus inout arguments in DWARF?

Can't help you there; last time I used Fortran, there was only one kind of argument. (Which can be entertaining when you pass "2" to a formal parameter that then gets modified by the callee. Redefining the value of "2" made for a very weird debugging experience.)

[SouraVX]

In D67563#1675361, @aprantl wrote:

In D67563#1675356, @aprantl wrote:

How do Fortran compilers represent regular versus inout arguments in DWARF?

According to godbolt.org, gfortran 8.2 emits the same DWARF for in and inout parameters. That doesn't help :-)

For Fortran snippet:

module foo
integer, parameter :: bar = 200
end module foo

$gfortran -g -c module.f90
DWARF:

0x00000055:     DW_TAG_constant
                  DW_AT_name    ("bar")
                  DW_AT_decl_file       ("mod.f90")
                  DW_AT_decl_line       (3)
                  DW_AT_decl_column     (0x27)
                  DW_AT_type    (0x0000006a "const integer(kind=4)")
                  DW_AT_external        (true)
                  DW_AT_const_value     (0xc8)

llvm/docs/LangRef.rst

.. code-block:: text
 
     !0 = !DILocation(line: 2900, column: 42, scope: !1, inlinedAt: !2)
 
 .. _DILocalVariable:
 
 DILocalVariable
 """""""""""""""
 
-``DILocalVariable`` nodes represent local variables in the source language. If
-the ``arg:`` field is set to non-zero, then this variable is a subprogram
-parameter, and it will be included in the ``variables:`` field of its
-:ref:`DISubprogram`.
+``DILocalVariable`` nodes represent local variables in the source
+language. If the ``arg:`` field is set to non-zero, then this variable
+is a subprogram parameter, and it will be included in the
+``variables:`` field of its :ref:`DISubprogram`. If the flag
+``DIFlagConstant`` is set the variable is a named constant in the
+source language.
 
 .. code-block:: text
 
     !0 = !DILocalVariable(name: "this", arg: 1, scope: !3, file: !2, line: 7,
                           type: !3, flags: DIFlagArtificial)
     !1 = !DILocalVariable(name: "x", arg: 2, scope: !4, file: !2, line: 7,
                           type: !3)
     !2 = !DILocalVariable(name: "y", scope: !5, file: !2, line: 7, type: !3)

llvm/include/llvm/BinaryFormat/Dwarf.def

 HANDLE_DW_AT(0x3b29, BORLAND_Delphi_return, 0, BORLAND)
 HANDLE_DW_AT(0x3b30, BORLAND_Delphi_frameptr, 0, BORLAND)
 HANDLE_DW_AT(0x3b31, BORLAND_closure, 0, BORLAND)
 // LLVM project extensions.
 HANDLE_DW_AT(0x3e00, LLVM_include_path, 0, LLVM)
 HANDLE_DW_AT(0x3e01, LLVM_config_macros, 0, LLVM)
 HANDLE_DW_AT(0x3e02, LLVM_isysroot, 0, LLVM)
 HANDLE_DW_AT(0x3e03, LLVM_tag_offset, 0, LLVM)
+HANDLE_DW_AT(0x3e04, LLVM_constant, 0, LLVM)
 // Apple extensions.
 HANDLE_DW_AT(0x3fe1, APPLE_optimized, 0, APPLE)
 HANDLE_DW_AT(0x3fe2, APPLE_flags, 0, APPLE)
 HANDLE_DW_AT(0x3fe3, APPLE_isa, 0, APPLE)
 HANDLE_DW_AT(0x3fe4, APPLE_block, 0, APPLE)
 HANDLE_DW_AT(0x3fe5, APPLE_major_runtime_vers, 0, APPLE)
 HANDLE_DW_AT(0x3fe6, APPLE_runtime_class, 0, APPLE)
 HANDLE_DW_AT(0x3fe7, APPLE_omit_frame_ptr, 0, APPLE)

llvm/include/llvm/IR/DebugInfoFlags.def

 
 HANDLE_DI_FLAG(0, Zero) // Use it as zero value.
                         // For example: void foo(DIFlags Flags = FlagZero).
 HANDLE_DI_FLAG(1, Private)
 HANDLE_DI_FLAG(2, Protected)
 HANDLE_DI_FLAG(3, Public)
 HANDLE_DI_FLAG((1 << 2), FwdDecl)
 HANDLE_DI_FLAG((1 << 3), AppleBlock)
-// Used to be BlockByRef, can be reused for anything except DICompositeType.
-HANDLE_DI_FLAG((1 << 4), ReservedBit4)
+HANDLE_DI_FLAG((1 << 4), Constant)
 HANDLE_DI_FLAG((1 << 5), Virtual)
 HANDLE_DI_FLAG((1 << 6), Artificial)
 HANDLE_DI_FLAG((1 << 7), Explicit)
 HANDLE_DI_FLAG((1 << 8), Prototyped)
 HANDLE_DI_FLAG((1 << 9), ObjcClassComplete)
 HANDLE_DI_FLAG((1 << 10), ObjectPointer)
 HANDLE_DI_FLAG((1 << 11), Vector)
 HANDLE_DI_FLAG((1 << 12), StaticMember)

llvm/include/llvm/IR/DebugInfoMetadata.h

public:
   DILocalScope *getScope() const {
     return cast<DILocalScope>(DIVariable::getScope());
   }
 
   bool isParameter() const { return Arg; }
   unsigned getArg() const { return Arg; }
   DIFlags getFlags() const { return Flags; }
 
+  bool isConstant() const { return getFlags() & FlagConstant; }
   bool isArtificial() const { return getFlags() & FlagArtificial; }
   bool isObjectPointer() const { return getFlags() & FlagObjectPointer; }
 
   /// Check that an argument is unmodified.
   bool isNotModified() const { return getFlags() & FlagArgumentNotModified; }
   /// Set the flag if an argument is unmodified.
   void setIsNotModified() { Flags |= FlagArgumentNotModified; }
 

llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp

if (DIVar)
     if (uint32_t AlignInBytes = DIVar->getAlignInBytes())
       addUInt(VariableDie, dwarf::DW_AT_alignment, dwarf::DW_FORM_udata,
               AlignInBytes);
 
   addSourceLine(VariableDie, DIVar);
   addType(VariableDie, Var.getType());
   if (Var.isArtificial())
     addFlag(VariableDie, dwarf::DW_AT_artificial);
+  if (Var.isConstant())
+    addFlag(VariableDie, dwarf::DW_AT_LLVM_constant);
 }
 
 void DwarfCompileUnit::applyLabelAttributes(const DbgLabel &Label,
                                             DIE &LabelDie) {
   StringRef Name = Label.getName();
   if (!Name.empty())
     addString(LabelDie, dwarf::DW_AT_name, Name);
   const auto *DILabel = Label.getLabel();

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h

public:
   unsigned getDebugLocListIndex() const { return DebugLocListIndex; }
   StringRef getName() const { return getVariable()->getName(); }
   const DbgValueLoc *getValueLoc() const { return ValueLoc.get(); }
   /// Get the FI entries, sorted by fragment offset.
   ArrayRef<FrameIndexExpr> getFrameIndexExprs() const;
   bool hasFrameIndexExprs() const { return !FrameIndexExprs.empty(); }
   void addMMIEntry(const DbgVariable &V);
 
-  // Translate tag to proper Dwarf tag.
+  /// Determine the appropriate tag for this variable.
   dwarf::Tag getTag() const {
-    // FIXME: Why don't we just infer this tag and store it all along?
     if (getVariable()->isParameter())
       return dwarf::DW_TAG_formal_parameter;
-
     return dwarf::DW_TAG_variable;
   }
 
   /// Return true if DbgVariable is artificial.
   bool isArtificial() const {
     if (getVariable()->isArtificial())
       return true;
     if (getType()->isArtificial())
       return true;
     return false;
   }
 
+  /// Return true if the source variable is an immutable constant value.
+  bool isConstant() const {
+    return getVariable()->isConstant();
+  }
+
   bool isObjectPointer() const {
     if (getVariable()->isObjectPointer())
       return true;
     if (getType()->isObjectPointer())
       return true;
     return false;
   }
 

llvm/test/DebugInfo/Generic/constants.ll

+; RUN: %llc_dwarf -O0 -filetype=obj -o - %s | llvm-dwarfdump - | FileCheck %s
+; REQUIRES: object-emission
+; CHECK: DW_TAG_variable
+; CHECK-NEXT: DW_AT_location
+; CHECK-NEXT: DW_AT_name {{.*}}"local_constant"
+; CHECK-NOT: DW_TAG
+; CHECK: DW_AT_LLVM_constant (true)
+
+; Function Attrs: noinline nounwind optnone ssp uwtable
+define void @foo() !dbg !14 {
+  %1 = alloca i32, align 4
+  call void @llvm.dbg.declare(metadata i32* %1, metadata !17, metadata !DIExpression()), !dbg !18
+  store i32 23, i32* %1, align 4, !dbg !18
+  ret void, !dbg !18
+}
+
+declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
+
+attributes #1 = { nounwind readnone speculatable }
+
+!llvm.module.flags = !{!9, !10}
+!llvm.dbg.cu = !{!2}
+
+!2 = distinct !DICompileUnit(language: DW_LANG_Swift, file: !3, producer: "handwritten", isOptimized: false, emissionKind: FullDebug)
+!3 = !DIFile(filename: "t.swift", directory: "/")
+!4 = !{}
+!7 = !DIBasicType(name: "Int32", size: 32, encoding: DW_ATE_signed)
+!9 = !{i32 2, !"Dwarf Version", i32 4}
+!10 = !{i32 2, !"Debug Info Version", i32 3}
+!14 = distinct !DISubprogram(name: "foo", scope: !3, file: !3, line: 2, type: !15, scopeLine: 2, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !4)
+!15 = !DISubroutineType(types: !16)
+!16 = !{null}
+!17 = !DILocalVariable(name: "local_constant", flags: DIFlagConstant, scope: !14, file: !3, line: 3, type: !7)
+!18 = !DILocation(line: 3, scope: !14)