From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12331 invoked by alias); 13 Jul 2002 00:09:47 -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 12320 invoked from network); 13 Jul 2002 00:09:45 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 13 Jul 2002 00:09:45 -0000 Received: from romulus.sfbay.redhat.com (IDENT:zaOb3/8KaNISj3xuh8viXOzRL+usvjTf@romulus.sfbay.redhat.com [172.16.27.251]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g6D0AUQ03535 for ; Fri, 12 Jul 2002 17:10:30 -0700 Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g6D09gB10221 for gdb-patches@sources.redhat.com; Fri, 12 Jul 2002 17:09:42 -0700 Date: Fri, 12 Jul 2002 18:15:00 -0000 From: Kevin Buettner Message-Id: <1020713000942.ZM10220@localhost.localdomain> To: gdb-patches@sources.redhat.com Subject: [PATCH RFA] dwarf2read.c: Accommodate older 64-bit DWARF2 format MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-07/txt/msg00290.txt.bz2 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;