Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [PATCH RFA] dwarf2read.c: Accommodate older 64-bit DWARF2 format
@ 2002-07-12 18:15 Kevin Buettner
  2002-07-13 16:53 ` Jim Blandy
  0 siblings, 1 reply; 3+ messages in thread
From: Kevin Buettner @ 2002-07-12 18:15 UTC (permalink / raw)
  To: gdb-patches

The patch below corresponds to a similar patch which was committed to
bfd/dwarf2.c a few weeks back.  See

    http://sources.redhat.com/ml/binutils/2002-06/msg00702.html

(and the rest of the thread).

The older, non-standard 64-bit format in question stores the initial
length as an 8-byte quantity without an escape value.  (Recall that
the current draft standard uses the value 0xffffffff in the first 4
bytes to indicate a 64-bit DWARF2 format.  The subsequent eight bytes
contain the length.)  For the older format, however, lengths greater
than 2~32 aren't very common which means that the initial 4 bytes is
almost always zero.  Since a length value of zero doesn't make sense for
the 32-bit format, this initial zero can be considered to be an escape
value which indicates the presence of the older 64-bit format.

It's true that we can't detect lengths greater than 4GB (for the old
format), but I don't think this matters much in practice.  If it
becomes necessary to handle values somewhat larger than 4GB, we could
allow other small values (such as the non-sensical values of 1, 2, and
3) to also be used as escape values which also indicate the presence
of the old format.  I don't think this will become necessary though
since the current DWARF 2/3 draft standard will likely be used for files
requiring larger lengths.

Okay to commit?

	* dwarf2read.c (read_initial_length): Handle older, non-standard,
	64-bit DWARF2 format.

Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.62
diff -u -p -r1.62 dwarf2read.c
--- dwarf2read.c	12 Jul 2002 19:55:10 -0000	1.62
+++ dwarf2read.c	12 Jul 2002 23:26:27 -0000
@@ -3907,6 +3907,18 @@ read_initial_length (bfd *abfd, char *bu
 	  cu_header->offset_size = 8;
 	}
     }
+  else if (retval == 0)
+    {
+      /* Handle (non-standard) 64-bit DWARF2 formats such as that used
+         by IRIX.  */
+      retval = bfd_get_64 (abfd, (bfd_byte *) buf);
+      *bytes_read = 8;
+      if (cu_header != NULL)
+	{
+	  cu_header->initial_length_size = 8;
+	  cu_header->offset_size = 8;
+	}
+    }
   else
     {
       *bytes_read = 4;


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH RFA] dwarf2read.c: Accommodate older 64-bit DWARF2 format
  2002-07-12 18:15 [PATCH RFA] dwarf2read.c: Accommodate older 64-bit DWARF2 format Kevin Buettner
@ 2002-07-13 16:53 ` Jim Blandy
  2002-07-16 16:30   ` Kevin Buettner
  0 siblings, 1 reply; 3+ messages in thread
From: Jim Blandy @ 2002-07-13 16:53 UTC (permalink / raw)
  To: Kevin Buettner; +Cc: gdb-patches


Approved, if you add discussion like the one included in your post to
the comment above read_initial_length.  (Whenever I'm about to write a
long explanation of a patch, I ask myself whether it wouldn't be
happier as a comment in the code.)

Kevin Buettner <kevinb@redhat.com> writes:

> The patch below corresponds to a similar patch which was committed to
> bfd/dwarf2.c a few weeks back.  See
> 
>     http://sources.redhat.com/ml/binutils/2002-06/msg00702.html
> 
> (and the rest of the thread).
> 
> The older, non-standard 64-bit format in question stores the initial
> length as an 8-byte quantity without an escape value.  (Recall that
> the current draft standard uses the value 0xffffffff in the first 4
> bytes to indicate a 64-bit DWARF2 format.  The subsequent eight bytes
> contain the length.)  For the older format, however, lengths greater
> than 2~32 aren't very common which means that the initial 4 bytes is
> almost always zero.  Since a length value of zero doesn't make sense for
> the 32-bit format, this initial zero can be considered to be an escape
> value which indicates the presence of the older 64-bit format.
> 
> It's true that we can't detect lengths greater than 4GB (for the old
> format), but I don't think this matters much in practice.  If it
> becomes necessary to handle values somewhat larger than 4GB, we could
> allow other small values (such as the non-sensical values of 1, 2, and
> 3) to also be used as escape values which also indicate the presence
> of the old format.  I don't think this will become necessary though
> since the current DWARF 2/3 draft standard will likely be used for files
> requiring larger lengths.
> 
> Okay to commit?
> 
> 	* dwarf2read.c (read_initial_length): Handle older, non-standard,
> 	64-bit DWARF2 format.
> 
> Index: dwarf2read.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dwarf2read.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 dwarf2read.c
> --- dwarf2read.c	12 Jul 2002 19:55:10 -0000	1.62
> +++ dwarf2read.c	12 Jul 2002 23:26:27 -0000
> @@ -3907,6 +3907,18 @@ read_initial_length (bfd *abfd, char *bu
>  	  cu_header->offset_size = 8;
>  	}
>      }
> +  else if (retval == 0)
> +    {
> +      /* Handle (non-standard) 64-bit DWARF2 formats such as that used
> +         by IRIX.  */
> +      retval = bfd_get_64 (abfd, (bfd_byte *) buf);
> +      *bytes_read = 8;
> +      if (cu_header != NULL)
> +	{
> +	  cu_header->initial_length_size = 8;
> +	  cu_header->offset_size = 8;
> +	}
> +    }
>    else
>      {
>        *bytes_read = 4;


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH RFA] dwarf2read.c: Accommodate older 64-bit DWARF2 format
  2002-07-13 16:53 ` Jim Blandy
@ 2002-07-16 16:30   ` Kevin Buettner
  0 siblings, 0 replies; 3+ messages in thread
From: Kevin Buettner @ 2002-07-16 16:30 UTC (permalink / raw)
  To: Jim Blandy; +Cc: gdb-patches

On Jul 13,  5:43pm, Jim Blandy wrote:

> Approved, if you add discussion like the one included in your post to
> the comment above read_initial_length.

Committed.

Since the patch that I ended up committing is quite different from
what I posted last week, I've appended it below.  The bits of actual C
code are identical to the patch I posted last week, but the changes to
the comment are new.  In addition to the requested changes, I took the
liberty of updating the comment to point at the current DWARF 3 draft
standard.  (The old link was broken due to reality.sgi.com being
decommissioned.)

	* dwarf2read.c (read_initial_length): Handle older, non-standard,
	64-bit DWARF2 format.

Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.62
diff -u -p -r1.62 dwarf2read.c
--- dwarf2read.c	12 Jul 2002 19:55:10 -0000	1.62
+++ dwarf2read.c	16 Jul 2002 20:56:44 -0000
@@ -3863,12 +3863,25 @@ read_address (bfd *abfd, char *buf, cons
   return retval;
 }
 
-/* Reads the initial length from a section.  The (draft) DWARF 2.1
+/* Read the initial length from a section.  The (draft) DWARF 3
    specification allows the initial length to take up either 4 bytes
    or 12 bytes.  If the first 4 bytes are 0xffffffff, then the next 8
    bytes describe the length and all offsets will be 8 bytes in length
    instead of 4.
 
+   An older, non-standard 64-bit format is also handled by this
+   function.  The older format in question stores the initial length
+   as an 8-byte quantity without an escape value.  Lengths greater
+   than 2^32 aren't very common which means that the initial 4 bytes
+   is almost always zero.  Since a length value of zero doesn't make
+   sense for the 32-bit format, this initial zero can be considered to
+   be an escape value which indicates the presence of the older 64-bit
+   format.  As written, the code can't detect (old format) lengths
+   greater than 4GB.  If it becomes necessary to handle lengths somewhat
+   larger than 4GB, we could allow other small values (such as the
+   non-sensical values of 1, 2, and 3) to also be used as escape values
+   indicating the presence of the old format.
+
    The value returned via bytes_read should be used to increment
    the relevant pointer after calling read_initial_length().
    
@@ -3879,14 +3892,18 @@ read_address (bfd *abfd, char *buf, cons
    
    [ Note:  read_initial_length() and read_offset() are based on the
      document entitled "DWARF Debugging Information Format", revision
-     2.1, draft 4, dated July 20, 2000.  This document was obtained
+     3, draft 8, dated November 19, 2001.  This document was obtained
      from:
 
-	http://reality.sgi.com/dehnert_engr/dwarf/dwarf2p1-draft4-000720.pdf
+	http://reality.sgiweb.org/davea/dwarf3-draft8-011125.pdf
      
      This document is only a draft and is subject to change.  (So beware.)
 
-     - Kevin, Aug 4, 2000
+     Details regarding the older, non-standard 64-bit format were
+     determined empirically by examining 64-bit ELF files produced
+     by the SGI toolchain on an IRIX 6.5 machine.
+
+     - Kevin, July 16, 2002
    ] */
 
 static LONGEST
@@ -3904,6 +3921,18 @@ read_initial_length (bfd *abfd, char *bu
       if (cu_header != NULL)
 	{
 	  cu_header->initial_length_size = 12;
+	  cu_header->offset_size = 8;
+	}
+    }
+  else if (retval == 0)
+    {
+      /* Handle (non-standard) 64-bit DWARF2 formats such as that used
+         by IRIX.  */
+      retval = bfd_get_64 (abfd, (bfd_byte *) buf);
+      *bytes_read = 8;
+      if (cu_header != NULL)
+	{
+	  cu_header->initial_length_size = 8;
 	  cu_header->offset_size = 8;
 	}
     }


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-07-16 21:09 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-12 18:15 [PATCH RFA] dwarf2read.c: Accommodate older 64-bit DWARF2 format Kevin Buettner
2002-07-13 16:53 ` Jim Blandy
2002-07-16 16:30   ` Kevin Buettner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox