From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30661 invoked by alias); 13 Jul 2002 22:43:24 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30654 invoked from network); 13 Jul 2002 22:43:23 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 13 Jul 2002 22:43:23 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id B6EBF5EA11; Sat, 13 Jul 2002 17:43:21 -0500 (EST) To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH RFA] dwarf2read.c: Accommodate older 64-bit DWARF2 format References: <1020713000942.ZM10220@localhost.localdomain> From: Jim Blandy Date: Sat, 13 Jul 2002 16:53:00 -0000 In-Reply-To: <1020713000942.ZM10220@localhost.localdomain> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-07/txt/msg00293.txt.bz2 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 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;