llvm-dwarf-dump: include type name for AT_containing_type

[fdeazeve]

Summary

Type attributes are currently printed as:

DW_AT_type    (<address> "<name>")

For example:

DW_AT_type    (0x00000086 "double")

However, containing_type attributes omit the name, for example:

DW_AT_containing_type    (0x00000086)

In order to make the dwarf dumps easier to read, and to have consistency
between the type-like attributes, this commit changes the way
DW_AT_containing_type is printed so that it includes the name of the
type it refers to:

DW_AT_containing_type    (0x00000086 "double")

[fdeazeve]

Is this something desirable? I did it because, while learning about DWARF, I found myself constantly having to bounce between nodes when inspecting these containing_type attributes.
I'd be happy to drop this if others don't feel it is needed.

W.r.t. testing I was a bit surprised that no tests under test/tools/llvm-dwarfdump failed, but this seems to be covered by DebugInfo tests. Please let me know if I missed a more appropriate test.

[fdeazeve]

The test timeouts seem to be happening on unrelated tests. Has anyone seen this before?

[dblaikie]

Sounds good to me - is there any canonical list in the DWARF spec of attributes that are types that we should consider? Or should we change this to work based on the type of the DIE being referenced, instead of the attribute doing the referencing?

[probinson]

In D127078#3561950, @dblaikie wrote:

Sounds good to me - is there any canonical list in the DWARF spec of attributes that are types that we should consider?

I'm not aware of any list of "attributes that point to types" and I think DW_AT_type/DW_AT_containing_type covers the interesting cases. I skimmed the list of all attributes (DWARF v5 section 7.5.4) and nothing obvious caught my eye.

Or should we change this to work based on the type of the DIE being referenced, instead of the attribute doing the referencing?

That would catch cases like DW_AT_sibling, if the sibling just happened to be a type, and I don't think that's really useful. (I know LLVM doesn't emit DW_AT_sibling, but it's still out there in the wild and the dumper needs to handle it.)

I'm fine with this patch as is.

[fdeazeve]

I'm not aware of any list of "attributes that point to types" and I think DW_AT_type/DW_AT_containing_type covers the interesting cases. I skimmed the list of all attributes (DWARF v5 section 7.5.4) and nothing obvious caught my eye.

That was my conclusion as well!

Or should we change this to work based on the type of the DIE being referenced, instead of the attribute doing the referencing?

That would catch cases like DW_AT_sibling, if the sibling just happened to be a type, and I don't think that's really useful. (I know LLVM doesn't emit DW_AT_sibling, but it's still out there in the wild and the dumper needs to handle it.)

Thanks for the checking, this is all new to me and I wasn't sure about the answer here.

I'll rebase and give these tests that timeout another try. If nobody else comments in a few days, would one of you be able to help me land this? I don't have commit privileges.

[fdeazeve]

Rebased

[fdeazeve]

The failures above have shown up in the build bots. I'll try to reproduce again with a different build config

[fdeazeve]

The subsequent build passed and I couldn't reproduce the timeouts locally, so I am assuming there is something intermittent going on?

Failing: https://lab.llvm.org/buildbot/#/builders/8/builds/3159
Passed: https://lab.llvm.org/buildbot/#/builders/8/builds/3160

[probinson]

In D127078#3594146, @fdeazeve wrote:

The subsequent build passed and I couldn't reproduce the timeouts locally, so I am assuming there is something intermittent going on?

Failing: https://lab.llvm.org/buildbot/#/builders/8/builds/3159
Passed: https://lab.llvm.org/buildbot/#/builders/8/builds/3160

Timeout failures for environmental reasons are not uncommon, if the next run passes there is nothing to worry about.

llvm/lib/DebugInfo/DWARF/DWARFDie.cpp

static void dumpAttribute(raw_ostream &OS, const DWARFDie &Die,
   // We have dumped the attribute raw value. For some attributes
   // having both the raw value and the pretty-printed value is
   // interesting. These attributes are handled below.
   if (Attr == DW_AT_specification || Attr == DW_AT_abstract_origin) {
     if (const char *Name =
             Die.getAttributeValueAsReferencedDie(FormValue).getName(
                 DINameKind::LinkageName))
       OS << Space << "\"" << Name << '\"';
-  } else if (Attr == DW_AT_type) {
+  } else if (Attr == DW_AT_type || Attr == DW_AT_containing_type) {
     DWARFDie D = resolveReferencedType(Die, FormValue);
     if (D && !D.isNULL()) {
       OS << Space << "\"";
       dumpTypeQualifiedName(D, OS);
       OS << '"';
     }
   } else if (Attr == DW_AT_APPLE_property_attribute) {
     if (Optional<uint64_t> OptVal = FormValue.getAsUnsignedConstant())

llvm/test/DebugInfo/Generic/containing-type-extension.ll

 ; RUN: %llc_dwarf -O0 -filetype=obj < %s > %t
 ; RUN: llvm-dwarfdump -v -debug-info %t | FileCheck %s
 
 ; Check that any type can have a vtable holder.
 ; CHECK: [[SP:.*]]: DW_TAG_structure_type
 ; CHECK-NOT: TAG
-; CHECK: DW_AT_containing_type [DW_FORM_ref4]
+; CHECK: DW_AT_containing_type [DW_FORM_ref4] ({{.*}} "int")
 ; CHECK: DW_AT_name {{.*}}"vtable"
 
 ; The code doesn't actually matter.
 define i32 @main() #0 !dbg !4 {
 entry:
   %retval = alloca i32, align 4
   store i32 0, i32* %retval
   ret i32 0, !dbg !10

llvm/test/DebugInfo/Generic/tu-composite.ll

 ; RUN: %llc_dwarf -filetype=obj -O0 < %s > %t
 ; RUN: llvm-dwarfdump -v -debug-info %t | FileCheck %s
 ; CHECK: [[TYPE:.*]]: DW_TAG_structure_type
 ; Make sure we correctly handle containing type of a struct being a type identifier.
-; CHECK-NEXT: DW_AT_containing_type [DW_FORM_ref4]       (cu + {{.*}} => {[[TYPE]]})
+; CHECK-NEXT: DW_AT_containing_type [DW_FORM_ref4]       (cu + {{.*}} => {[[TYPE]]} "C")
 ; CHECK-NEXT: DW_AT_name {{.*}}"C"
 
 ; Make sure we correctly handle context of a subprogram being a type identifier.
 ; CHECK: [[SP:.*]]: DW_TAG_subprogram
 ; CHECK: DW_AT_name {{.*}}"foo"
 ; Make sure we correctly handle containing type of a subprogram being a type identifier.
-; CHECK: DW_AT_containing_type [DW_FORM_ref4]       (cu + {{.*}} => {[[TYPE]]})
+; CHECK: DW_AT_containing_type [DW_FORM_ref4]       (cu + {{.*}} => {[[TYPE]]} "C")
 ; CHECK: DW_TAG_formal_parameter
 ; CHECK: NULL
 ; CHECK: NULL
 
 ; CHECK: [[TYPE2:.*]]: DW_TAG_structure_type
 ; CHECK: DW_AT_name {{.*}}"bar"
 ; CHECK: DW_TAG_structure_type
 ; CHECK: DW_AT_name {{.*}}"D"

llvm/test/DebugInfo/X86/containing-type-extension-rust.ll

 ; RUN: llc -O0 -filetype=obj < %s > %t
 ; RUN: llvm-dwarfdump -v -debug-info %t | FileCheck %s
 
 ; Check that any type can have a vtable holder.
 ; CHECK: [[SP:.*]]: DW_TAG_structure_type
 ; CHECK-NOT: TAG
-; CHECK: DW_AT_containing_type [DW_FORM_ref4]
+; CHECK: DW_AT_containing_type [DW_FORM_ref4] ({{.*}} "f64")
 ; CHECK: DW_AT_name [DW_FORM_strp] {{.*}}= "vtable")
 
 ; This was compiled using
 ; rustc -g --emit=llvm-ir t2.rs
 ; ... and then edited by hand, because rustc is using a somewhat older llvm.
 ;
 ; t2.rs is:
 ;