[PATCH] D41264: Fix faulty assertion for void type in debug info

[David Blaikie via llvm-commits]

On Wed, Dec 20, 2017 at 9:00 AM Paul Robinson via Phabricator via
llvm-commits <llvm-commits at lists.llvm.org> wrote:

> probinson added a comment.
>
> In https://reviews.llvm.org/D41264#959575, @aprantl wrote:
>
> >   0x00000068:     DW_TAG_typedef
> >                     DW_AT_name        ("_Nodeptr")
> >                     DW_AT_decl_file   ("/tmp/t.cpp")
> >                     DW_AT_decl_line   (2)
> >
> >   0x0000006f:     NULL
> >
> >
> > this also looks weird, but is apparently sort of legal DWARF:
> >
> > > For example, in C and C++ the language implementation can provide an
> unspecified type entry with the name “void” which can be referenced by the
> type attribute of pointer types and typedef declarations for ’void’.
> >
> > although it would be nicer to use DW_TAG_unspecified_type instead.
> >
> > Based on this it looks like we should allow this case.
>
>
> I didn't think it was legal either, but the description of DW_TAG_typedef
> does say it "may" have a DW_AT_type, and even discusses when it's
> appropriate to leave it out.
>
> Using `void` as the return type of a subprogram is explicitly represented
> as omitting DW_AT_type from the subprogram DIE, and that's probably where
> the nullptr idea came from.
>
> A typedef of `void *`  goes to a DW_TAG_pointer_type which is required to
> have at DW_AT_type, which I think we do emit as DW_TAG_unspecified_type.
> So, for consistency I'd think we might want typedef to do something
> similar.  But, omitting is legal.
>

Seems Clang and GCC both emit void* as a DW_TAG_pointer_type without any
DW_AT_type attribute, FWIW. (minor difference: GCC puts a DW_AT_byte_size
on it, and Clang omits that)


>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D41264
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180102/9cad5fc1/attachment.html>