[PATCH] Accept DWARF 3-format debug info

[PATCH] Accept DWARF 3-format debug info

[Julian Brown]

[-- Attachment #1: Type: text/plain, Size: 810 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.

ARMCC's support for DWARF 3 is superior to its DWARF 2 support, and GDB 
apparently supports much of DWARF 3 already. This patch allows DWARF 3 
format debug info to be accepted by gdb.

(Some things are notably missing from the DWARF 3 support -- one thing 
I've noticed so far is lack of support for DW_TAG_partial_unit, but RVDS 
2.2 doesn't seem to need that. A couple of other minor things will be 
addressed in followup patches.)

Tested with cross to arm-none-eabi, and natively on 
x86_64-unknown-linux-gnu. OK to apply on mainline?

Cheers,

Julian

ChangeLog (Daniel Jacobowitz):

     * gdb/dwarf2read.c (partial_read_comp_unit_head): Accept version 3.

[-- Attachment #2: arm-dwarf3.patch --]
[-- Type: text/x-patch, Size: 600 bytes --]

Index: src/gdb/dwarf2read.c
===================================================================
--- src.orig/gdb/dwarf2read.c	2005-03-01 12:09:19.000000000 -0800
+++ src/gdb/dwarf2read.c	2005-03-07 06:00:16.000000000 -0800
@@ -1312,7 +1312,7 @@ partial_read_comp_unit_head (struct comp
 
   info_ptr = read_comp_unit_head (header, info_ptr, abfd);
 
-  if (header->version != 2)
+  if (header->version != 2 && header->version != 3)
     error (_("Dwarf Error: wrong version in compilation unit header "
 	   "(is %d, should be %d) [in module %s]"), header->version,
 	   2, bfd_get_filename (abfd));

Re: [PATCH] Accept DWARF 3-format debug info

[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.
>
> ARMCC's support for DWARF 3 is superior to its DWARF 2 support, and
> GDB apparently supports much of DWARF 3 already. This patch allows
> DWARF 3 format debug info to be accepted by gdb.
>
> (Some things are notably missing from the DWARF 3 support -- one thing
> I've noticed so far is lack of support for DW_TAG_partial_unit, but
> RVDS 2.2 doesn't seem to need that. A couple of other minor things
> will be addressed in followup patches.)

I think this patch is right.  It's true that GDB doesn't support all
of DWARF 3, but GDB's general philosophy is to garner as much
information as it can, and punt the rest, which works well with
DWARF's philosophy.  So GDB shouldn't just punt entire compilation
units because they're marked as DWARF 3.

First, please add yourself to the Write After Approval list in
gdb/MAINTAINERS, with an appropriate ChangeLog entry.

Then, go ahead and put in the patch as a separate commit.

Thanks!

Re: [PATCH] Accept DWARF 3-format debug info

[Daniel Jacobowitz]

On Thu, Jun 08, 2006 at 04:25:42PM -0700, Jim Blandy wrote:
> I think this patch is right.  It's true that GDB doesn't support all
> of DWARF 3, but GDB's general philosophy is to garner as much
> information as it can, and punt the rest, which works well with
> DWARF's philosophy.  So GDB shouldn't just punt entire compilation
> units because they're marked as DWARF 3.

I agree.

There seems to be one structural change in .debug_info tied to the
version number (there's also the initial lengths, but we already
support that).  That is:

References that use the attribute form DW_FORM_ref_addr are specified
to be four bytes in the DWARF 32-bit format and eight bytes in the
DWARF 64-bit format, while DWARF Version 2 specifies that such
references have the same size as anaddress on the target system (see
Sections 7.4 and 7.5.4).

I see two places (skip_one_die and read_attribute_value) that are
affected.  So, this should be an easy item to fix.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] Accept DWARF 3-format debug info

[Eli Zaretskii]

> Cc: gdb-patches@sourceware.org,  Daniel Jacobowitz <dan@codesourcery.com>
> From: Jim Blandy <jimb@codesourcery.com>
> Date: Thu, 08 Jun 2006 16:25:42 -0700
> 
> I think this patch is right.  It's true that GDB doesn't support all
> of DWARF 3, but GDB's general philosophy is to garner as much
> information as it can, and punt the rest, which works well with
> DWARF's philosophy.  So GDB shouldn't just punt entire compilation
> units because they're marked as DWARF 3.

I agree with the philosophy, but the devil is usually in the
details...

In this case, what will happen when GDB sees a DWARF-3 feature it
doesn't yet support?  I think we should make sure it displays a
warning message, instead of throwing an internal error (or some
similar fatal reaction).

Re: [PATCH] Accept DWARF 3-format debug info

[Daniel Jacobowitz]

On Fri, Jun 09, 2006 at 10:28:07AM +0300, Eli Zaretskii wrote:
> In this case, what will happen when GDB sees a DWARF-3 feature it
> doesn't yet support?  I think we should make sure it displays a
> warning message, instead of throwing an internal error (or some
> similar fatal reaction).

Same thing that happens when we see a DWARF-2 feature we don't support
;-)  If I remember right, we support most of the DWARF-3 changes
relative to DWARF-2 at this point, though there's at least a few bits
of the original DWARF-2 that we're missing or bad at.

GCC is actually a DWARF-3 producer in almost all ways.  It just didn't
bump the version number, to avoid upsetting consumers, since most of
the changes are forwards-compatible.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] Accept DWARF 3-format debug info

[Julian Brown]

Eli Zaretskii wrote:
>>Cc: gdb-patches@sourceware.org,  Daniel Jacobowitz <dan@codesourcery.com>
>>From: Jim Blandy <jimb@codesourcery.com>
>>Date: Thu, 08 Jun 2006 16:25:42 -0700
>>
>>I think this patch is right.  It's true that GDB doesn't support all
>>of DWARF 3, but GDB's general philosophy is to garner as much
>>information as it can, and punt the rest, which works well with
>>DWARF's philosophy.  So GDB shouldn't just punt entire compilation
>>units because they're marked as DWARF 3.
> 
> 
> I agree with the philosophy, but the devil is usually in the
> details...
> 
> In this case, what will happen when GDB sees a DWARF-3 feature it
> doesn't yet support?  I think we should make sure it displays a
> warning message, instead of throwing an internal error (or some
> similar fatal reaction).

AIUI, the ideal is to just ignore the bits of DWARF which aren't yet 
understood, though I don't know how well that works in practice. The 
partial-unit case certainly causes unpleasant crashes at present, but 
I'd hope that that's an exception rather than a rule. (I, or one of the 
other sourcerers, may get to that particular case later.)

Cheers,

Julian

Re: [PATCH] Accept DWARF 3-format debug info

[Eli Zaretskii]

> Date: Fri, 09 Jun 2006 13:18:22 +0100
> From: Julian Brown <julian@codesourcery.com>
> CC: Jim Blandy <jimb@codesourcery.com>,  gdb-patches@sourceware.org, 
>  dan@codesourcery.com
> 
> AIUI, the ideal is to just ignore the bits of DWARF which aren't yet 
> understood

Ignoring them is okay with me.

Re: [PATCH] Accept DWARF 3-format debug info

[Eli Zaretskii]

> Date: Fri, 9 Jun 2006 08:25:33 -0400
> From: Daniel Jacobowitz <dan@codesourcery.com>
> Cc: Jim Blandy <jimb@codesourcery.com>, julian@codesourcery.com,
> 	gdb-patches@sourceware.org
> 
> On Fri, Jun 09, 2006 at 10:28:07AM +0300, Eli Zaretskii wrote:
> > In this case, what will happen when GDB sees a DWARF-3 feature it
> > doesn't yet support?  I think we should make sure it displays a
> > warning message, instead of throwing an internal error (or some
> > similar fatal reaction).
> 
> Same thing that happens when we see a DWARF-2 feature we don't support
> ;-)

Which is -- what?  (I really don't know.)

> GCC is actually a DWARF-3 producer in almost all ways.  It just didn't
> bump the version number, to avoid upsetting consumers, since most of
> the changes are forwards-compatible.

Well, the same reasons GCC had to avoid upsetting consumers might be
relevant for us as well, don't you think?

Re: [PATCH] Accept DWARF 3-format debug info

[Daniel Jacobowitz]

On Fri, Jun 09, 2006 at 07:41:54PM +0300, Eli Zaretskii wrote:
> > On Fri, Jun 09, 2006 at 10:28:07AM +0300, Eli Zaretskii wrote:
> > > In this case, what will happen when GDB sees a DWARF-3 feature it
> > > doesn't yet support?  I think we should make sure it displays a
> > > warning message, instead of throwing an internal error (or some
> > > similar fatal reaction).
> > 
> > Same thing that happens when we see a DWARF-2 feature we don't support
> > ;-)
> 
> Which is -- what?  (I really don't know.)

It depends.  We try to ignore it.  However, often debugging information
relies on some new construct in place of an older, less expressive one.

Syntactically, GDB will cope with most unrecognized constructs just
fine.  Semantically, however, if it doesn't recognize something it may
not cope well with debugging.  This is already very true for DWARF-2;
some of the other patches Julian will be posting are along those lines.

> > GCC is actually a DWARF-3 producer in almost all ways.  It just didn't
> > bump the version number, to avoid upsetting consumers, since most of
> > the changes are forwards-compatible.
> 
> Well, the same reasons GCC had to avoid upsetting consumers might be
> relevant for us as well, don't you think?

No, because we're a consumer of this information, not a producer.  This
is a "conservative in what you generate, liberal in what you accept"
sort of situation.  Strictly speaking, we're handling a lot of tags in
DWARF-2 that aren't really part of DWARF-2 - but that's harmless.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] Accept DWARF 3-format debug info

[Eli Zaretskii]

> Date: Fri, 9 Jun 2006 13:20:13 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Jim Blandy <jimb@codesourcery.com>, julian@codesourcery.com,
> 	gdb-patches@sourceware.org
> 
> Strictly speaking, we're handling a lot of tags in
> DWARF-2 that aren't really part of DWARF-2 - but that's harmless.

If we do that silently and harmlessly, it is okay, IMO.

Re: [PATCH] Accept DWARF 3-format debug info

[Mark Kettenis]

> Date: Thu, 8 Jun 2006 19:59:12 -0400
> From: Daniel Jacobowitz <dan@codesourcery.com>
> 
> On Thu, Jun 08, 2006 at 04:25:42PM -0700, Jim Blandy wrote:
> > I think this patch is right.  It's true that GDB doesn't support all
> > of DWARF 3, but GDB's general philosophy is to garner as much
> > information as it can, and punt the rest, which works well with
> > DWARF's philosophy.  So GDB shouldn't just punt entire compilation
> > units because they're marked as DWARF 3.
> 
> I agree.
> 
> There seems to be one structural change in .debug_info tied to the
> version number (there's also the initial lengths, but we already
> support that).  That is:
> 
> References that use the attribute form DW_FORM_ref_addr are specified
> to be four bytes in the DWARF 32-bit format and eight bytes in the
> DWARF 64-bit format, while DWARF Version 2 specifies that such
> references have the same size as anaddress on the target system (see
> Sections 7.4 and 7.5.4).
> 
> I see two places (skip_one_die and read_attribute_value) that are
> affected.  So, this should be an easy item to fix.

If this hasn't been fixed yet, could you add appropriate FIXME's at
those places?  Might save us some time tracking down bugs in the
future.

Mark

Re: [PATCH] Accept DWARF 3-format debug info

[Jim Blandy]

Mark Kettenis <mark.kettenis@xs4all.nl> writes:
>> Date: Thu, 8 Jun 2006 19:59:12 -0400
>> From: Daniel Jacobowitz <dan@codesourcery.com>
>> 
>> On Thu, Jun 08, 2006 at 04:25:42PM -0700, Jim Blandy wrote:
>> > I think this patch is right.  It's true that GDB doesn't support all
>> > of DWARF 3, but GDB's general philosophy is to garner as much
>> > information as it can, and punt the rest, which works well with
>> > DWARF's philosophy.  So GDB shouldn't just punt entire compilation
>> > units because they're marked as DWARF 3.
>> 
>> I agree.
>> 
>> There seems to be one structural change in .debug_info tied to the
>> version number (there's also the initial lengths, but we already
>> support that).  That is:
>> 
>> References that use the attribute form DW_FORM_ref_addr are specified
>> to be four bytes in the DWARF 32-bit format and eight bytes in the
>> DWARF 64-bit format, while DWARF Version 2 specifies that such
>> references have the same size as anaddress on the target system (see
>> Sections 7.4 and 7.5.4).
>> 
>> I see two places (skip_one_die and read_attribute_value) that are
>> affected.  So, this should be an easy item to fix.
>
> If this hasn't been fixed yet, could you add appropriate FIXME's at
> those places?  Might save us some time tracking down bugs in the
> future.

I have a patch; I just haven't gotten to running a regression test.
It's pretty trivial.

RFC: Support DW_FORM_ref_addr as described in DWARF 3

[Jim Blandy]

Daniel Jacobowitz <dan@codesourcery.com> writes:
> On Thu, Jun 08, 2006 at 04:25:42PM -0700, Jim Blandy wrote:
>> I think this patch is right.  It's true that GDB doesn't support all
>> of DWARF 3, but GDB's general philosophy is to garner as much
>> information as it can, and punt the rest, which works well with
>> DWARF's philosophy.  So GDB shouldn't just punt entire compilation
>> units because they're marked as DWARF 3.
>
> I agree.
>
> There seems to be one structural change in .debug_info tied to the
> version number (there's also the initial lengths, but we already
> support that).  That is:
>
> References that use the attribute form DW_FORM_ref_addr are specified
> to be four bytes in the DWARF 32-bit format and eight bytes in the
> DWARF 64-bit format, while DWARF Version 2 specifies that such
> references have the same size as anaddress on the target system (see
> Sections 7.4 and 7.5.4).
>
> I see two places (skip_one_die and read_attribute_value) that are
> affected.  So, this should be an easy item to fix.

Here's a patch for this, as promised; how does it look?

2006-06-20  Jim Blandy  <jimb@codesourcery.com>

	Support DW_FORM_ref_addr as described in DWARF 3.
	* dwarf2read.c (struct comp_unit_head): New field, ref_addr_size.
	(read_comp_unit_head): Initialize CU's ref_addr_size field.
	(skip_one_die): Use ref_addr_size for DW_FORM_ref_addr attributes.
	(read_ref_addr): New function.
	(read_attribute_value): Call it.

Index: gdb/dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.199
diff -u -p -r1.199 dwarf2read.c
--- gdb/dwarf2read.c	14 Jun 2006 15:06:35 -0000	1.199
+++ gdb/dwarf2read.c	20 Jun 2006 18:18:46 -0000
@@ -233,6 +233,19 @@ struct comp_unit_head
   /* Size of the length field; either 4 or 12.  */
   unsigned int initial_length_size;
 
+  /* The size of a DW_FORM_ref_addr attribute.  This depends on
+     VERSION, above.
+
+     - For versions 2 and earlier, DW_FORM_ref_addr is the size of an
+       address, as given in the 'address size' field of the compilation
+       unit header.
+
+     - For versions 3 and later, a DW_FORM_ref_addr value is four bytes
+       in the 32-bit DWARF format, and eight bytes in the 64-bit DWARF
+       format --- in other words, it matches whatever size offset is
+       otherwise used to index the debugging info.  */
+  unsigned int ref_addr_size;
+
   /* Offset to the first byte of this compilation unit header in the
      .debug_info section, for resolving relative reference dies.  */
   unsigned int offset;
@@ -804,6 +817,9 @@ static CORE_ADDR read_address (bfd *, gd
 static LONGEST read_initial_length (bfd *, gdb_byte *,
                                     struct comp_unit_head *, unsigned int *);
 
+static LONGEST read_ref_addr (bfd *, gdb_byte *, const struct comp_unit_head *,
+                              unsigned int *);
+
 static LONGEST read_offset (bfd *, gdb_byte *, const struct comp_unit_head *,
                             unsigned int *);
 
@@ -1293,6 +1309,12 @@ read_comp_unit_head (struct comp_unit_he
     internal_error (__FILE__, __LINE__,
 		    _("read_comp_unit_head: dwarf from non elf file"));
   cu_header->signed_addr_p = signed_addr;
+
+  if (cu_header->version < 3)
+    cu_header->ref_addr_size = cu_header->addr_size;
+  else
+    cu_header->ref_addr_size = cu_header->offset_size;
+
   return info_ptr;
 }
 
@@ -2224,7 +2246,7 @@ skip_one_die (gdb_byte *info_ptr, struct
 	{
 	case DW_FORM_addr:
 	case DW_FORM_ref_addr:
-	  info_ptr += cu->header.addr_size;
+	  info_ptr += cu->header.ref_addr_size;
 	  break;
 	case DW_FORM_data1:
 	case DW_FORM_ref1:
@@ -5733,7 +5755,7 @@ read_attribute_value (struct attribute *
     {
     case DW_FORM_addr:
     case DW_FORM_ref_addr:
-      DW_ADDR (attr) = read_address (abfd, info_ptr, cu, &bytes_read);
+      DW_ADDR (attr) = read_ref_addr (abfd, info_ptr, &cu->header, &bytes_read);
       info_ptr += bytes_read;
       break;
     case DW_FORM_block2:
@@ -6027,6 +6049,32 @@ read_initial_length (bfd *abfd, gdb_byte
   return length;
 }
 
+
+static LONGEST
+read_ref_addr (bfd *abfd, gdb_byte *buf, const struct comp_unit_head *cu_header,
+               unsigned int *bytes_read)
+{
+  LONGEST retval = 0;
+
+  switch (cu_header->ref_addr_size)
+    {
+    case 4:
+      retval = bfd_get_32 (abfd, buf);
+      *bytes_read = 4;
+      break;
+    case 8:
+      retval = bfd_get_64 (abfd, buf);
+      *bytes_read = 8;
+      break;
+    default:
+      internal_error (__FILE__, __LINE__,
+		      _("read_ref_addr: bad switch [in module %s]"),
+		      bfd_get_filename (abfd));
+    }
+
+  return retval;
+}
+
 /* Read an offset from the data stream.  The size of the offset is
    given by cu_header->offset_size.  */
 

Re: RFC: Support DW_FORM_ref_addr as described in DWARF 3

[Daniel Jacobowitz]

On Tue, Jun 20, 2006 at 12:53:34PM -0700, Jim Blandy wrote:
> Here's a patch for this, as promised; how does it look?

Mostly OK.  One typo:

> @@ -2224,7 +2246,7 @@ skip_one_die (gdb_byte *info_ptr, struct
>  	{
>  	case DW_FORM_addr:
>  	case DW_FORM_ref_addr:
> -	  info_ptr += cu->header.addr_size;
> +	  info_ptr += cu->header.ref_addr_size;
>  	  break;
>  	case DW_FORM_data1:
>  	case DW_FORM_ref1:
> @@ -5733,7 +5755,7 @@ read_attribute_value (struct attribute *
>      {
>      case DW_FORM_addr:
>      case DW_FORM_ref_addr:
> -      DW_ADDR (attr) = read_address (abfd, info_ptr, cu, &bytes_read);
> +      DW_ADDR (attr) = read_ref_addr (abfd, info_ptr, &cu->header, &bytes_read);
>        info_ptr += bytes_read;
>        break;
>      case DW_FORM_block2:

I don't think you want to use read_ref_addr for DW_FORM_addr.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] Accept DWARF 3-format debug info

[David Anderson]

Damiel writes, about a supposed change in DW_FORM_ref_addr:

>References that use the attribute form DW_FORM_ref_addr are specified
        >to be four bytes in the DWARF 32-bit format and eight bytes in
        the
        >DWARF 64-bit format, while DWARF Version 2 specifies that such
        >references have the same size as an address on the target
        system >(see Sections 7.4 and 7.5.4).
        
        
This is a correct observation, but *the dwarf 2 document was wrong*.

We did this late in 1992 and simply botched the document.
Confusion and tiredness :-(
Same size as an address simply makes no sense, never did.

Till very recently I don't think anyone used DW_FORM_ref_addr.
I did get an inquiry from one person (about dwarfdump) that proved
one compiler supplier believes the dwarf2 document on this point. Recent
inquiry, I mean.

There should still be  FAQ on dwarf.freestandards.org which
says the DWARF2 doc was/is wrong (I wrote that FAQ).

What the dwarf3 doc says is what we always intended. It's an offset,
not an address. Misleading name of the form...

David Anderson (davea@sgi.com, writing from home)