[PATCH] Interpret DW_TAG_unspecified_type as void

[PATCH] Interpret DW_TAG_unspecified_type as void

[Julian Brown]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

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?

Cheers,

Julian

ChangeLog (Daniel Jacobowitz):

     * dwarf2read.c (read_unspecified_type): New function.
     (read_type_die): Handle DW_TAG_unspecified_type.

[-- Attachment #2: unspecified-type-void.patch --]
[-- Type: text/x-patch, Size: 1186 bytes --]

Index: src/gdb/dwarf2read.c
===================================================================
--- src.orig/gdb/dwarf2read.c	2005-03-07 06:00:16.000000000 -0800
+++ src/gdb/dwarf2read.c	2005-03-07 07:27:38.000000000 -0800
@@ -4992,6 +4992,23 @@ read_subrange_type (struct die_info *die
   set_die_type (die, range_type, cu);
 }
   
+static void
+read_unspecified_type (struct die_info *die, struct dwarf2_cu *cu)
+{
+  struct type *type;
+  struct attribute *attr;
+
+  if (die->type)
+    return;
+
+  /* For now, we only support the C meaning of an unspecified type: void.  */
+
+  attr = dwarf2_attr (die, DW_AT_name, cu);
+  type = init_type (TYPE_CODE_VOID, 0, 0, attr ? DW_STRING (attr) : "",
+		    cu->objfile);
+
+  set_die_type (die, type, cu);
+}
 
 /* Read a whole compilation unit into a linked list of dies.  */
 
@@ -7526,6 +7543,9 @@ read_type_die (struct die_info *die, str
     case DW_TAG_base_type:
       read_base_type (die, cu);
       break;
+    case DW_TAG_unspecified_type:
+      read_unspecified_type (die, cu);
+      break;
     default:
       complaint (&symfile_complaints, _("unexepected tag in read_type_die: '%s'"),
 		 dwarf_tag_name (die->tag));

Re: [PATCH] Interpret DW_TAG_unspecified_type as void

[Jim Blandy]

Julian Brown <julian@codesourcery.com> writes:
> 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?

Yes, this looks fine --- thanks!

If the change was written by Daniel, and you're merging it on his
behalf, I think our practice is to use a ChangeLog entry like this:

2006-06-12  Daniel Jacobowitz  <dan@codesourcery.com>

	* dwarf2read.c (read_unspecified_type): New function.
	(read_type_die): Handle DW_TAG_unspecified_type.
        (Committed by Julian Brown.)

Re: [PATCH] Interpret DW_TAG_unspecified_type as void

[Daniel Jacobowitz]

On Tue, Jun 13, 2006 at 04:42:31PM -0700, Jim Blandy wrote:
> Yes, this looks fine --- thanks!
> 
> If the change was written by Daniel, and you're merging it on his
> behalf, I think our practice is to use a ChangeLog entry like this:

I don't know if I'd go so far as to say we had a practice... you can
find an example of just about every way of doing this in
gdb/ChangeLog*.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] Interpret DW_TAG_unspecified_type as void

[Mark Kettenis]

> 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'.

Re: [PATCH] Interpret DW_TAG_unspecified_type as void

[Richard Earnshaw]

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.