[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