[PATCH] D52223: [dwarfdump] Verify DW_AT_type.

Adrian Prantl via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 18 10:53:24 PDT 2018


aprantl added inline comments.


================
Comment at: llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp:192
+                         Die.getTag() == DW_TAG_variable ||
+                         Die.getTag() == DW_TAG_array_type)) {
+      error() << "DIE with tag " << TagString(Die.getTag())
----------------
probinson wrote:
> aprantl wrote:
> > Have you tested this? I have a vague recollection that older versions of clang emitted (void) as no type. You may need to add an exception for DWARF2 or something.
> > 
> > Found it: <rdar://problem/13291085> (For everyone else: it's a bugreport about exactly this)
> @aprantl I am unclear what it means to have a variable/parameter with type void, or an array whose elements are type void?  (pointer to void, sure, but then there will be a DW_AT_type.)
> Omitting the type is how you describe a function with void return type, but offhand I can't think of any other situation where that should occur.
> or do you mean there are older buggy compilers out there and we should tolerate their bugs?
The bugreport is about a clang producing the type for `(void *)` as 

```
DW_TAG_pointer_type
NULL
```

I had thought that newer clangs are emitting this as 

```
DW_TAG_pointer_type
  DW_AT_TYPE [1]

[1] DW_TAG_unspecified_type
        DW_AT_name "void"
```

but, no, this is still how it is represented, and frankly, changing it doesn't seem to have any benefits.

Since, as you point out, you can't have an array[void] or a variable of type void, my concern doesn't really apply to this patch.


Repository:
  rL LLVM

https://reviews.llvm.org/D52223





More information about the llvm-commits mailing list