This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Interpret DW_TAG_unspecified_type as void
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: Julian Brown <julian at codesourcery dot com>, gdb-patches at sourceware dot org, Daniel Jacobowitz <dan at codesourcery dot com>
- Date: Mon, 19 Jun 2006 13:57:36 +0100
- Subject: Re: [PATCH] Interpret DW_TAG_unspecified_type as void
- References: <448969B2.9010202@codesourcery.com> <200606180114.k5I1E5nu017691@elgar.sibelius.xs4all.nl>
On Sun, 2006-06-18 at 02:14, Mark Kettenis wrote:
> > Date: Fri, 09 Jun 2006 13:29:38 +0100
> > From: Julian Brown <julian@codesourcery.com>
> >
> > Hi,
> >
> > This is part of a series of patches from a CodeSourcery branch which
> > enable the output of ARM's RVCT 2.2 compiler to be debugged with gdb.
> >
> > This patch handles the C/C++ interpretation of the DWARF 3 construct
> > DW_TAG_unspecified_type as void. This is used in representing e.g.
> > pointer-to-void types. Other languages will currently be handled in
> > exactly the same way; though I'm not entirely sure if that's a sensible
> > default, I don't know what would be better. (Re: section 5.2 of the
> > DWARF 3 doc.)
> >
> > Tested natively on x86_64-unknown-linux-gnu and cross to arm-none-eabi
> > with no change in results. Tests against the ARM compiler are improved
> > somewhat.
> >
> > OK to apply?
>
> I haven't looked into what the DWARF spec actually says, but
> traditionally unspecified types in C default to 'int', not 'void'.
5.2 Unspecified Type Entries
Some languages have constructs in which a type may be left
unspecified or the absence of a type may be explicitly
indicated.
An unspecified (implicit, unknown, ambiguous or nonexistent)
type is represented by a debugging information entry with the
tag DW_TAG_unspecified_type. If a name has been given to the
type, then the corresponding unspecified type entry has a
DW_AT_name attribute whose value is a null-terminated string
containing the name as it appears in the source program.
The interpretation of this debugging information entry is
intentionally left flexible to allow it to be interpreted
appropriately in different languages. 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'
(see Sections 5.3 and 5.4, respectively). As another example, in
Ada such an unspecified type entry can be referred to by the
type attribute of an access type where the denoted type is
incomplete (the name is declared as a type but the definition is
deferred to a separate compilation unit).
So in this case we do mean void (in particular void* means pointer to
unspecified type). The 'defaults to int' is more an implicit type than
an unspecified type, and the third paragraph above makes it cleat that
void is what is meant for C.
R.