From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4316 invoked by alias); 27 Apr 2012 18:16:11 -0000 Received: (qmail 4293 invoked by uid 22791); 27 Apr 2012 18:16:09 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Apr 2012 18:15:48 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3RIFkYg010849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Apr 2012 14:15:46 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3RIFjTC028118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 Apr 2012 14:15:45 -0400 From: Tom Tromey To: dje@google.com (Doug Evans) Cc: gdb-patches@sourceware.org, ccoutant@google.com, saugustine@google.com Subject: Re: [RFA 3/3] Initial Fission support, the actual Fission stuff References: <20120418185738.277DB2461AF@ruffy.mtv.corp.google.com> Date: Fri, 27 Apr 2012 18:20:00 -0000 In-Reply-To: <20120418185738.277DB2461AF@ruffy.mtv.corp.google.com> (Doug Evans's message of "Wed, 18 Apr 2012 11:57:38 -0700 (PDT)") Message-ID: <87397p3usu.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-04/txt/msg01022.txt.bz2 >>>>> "Doug" == Doug Evans writes: Doug> * symfile.h (dwarf2_debug_sections): New members addr, ref. I think you have to update xcoffread.c as well. Doug> + struct bfd *dwo_bfd; I think it is more normal to use the 'bfd' typedef. I see a few uses of 'struct bfd' in the tree, but 10x more for the typedef. Doug> + /* We can't set abfd until now because the section may be empty or Doug> + not present, in which case section->asection will be NULL. */ Doug> + abfd = section->asection->owner; Doug> + Doug> if (types_htab == NULL) Doug> - types_htab = allocate_signatured_type_table (objfile); Doug> + { Doug> + if (dwo_file) Doug> + types_htab = allocate_dwo_unit_table (objfile); Doug> + else Doug> + types_htab = allocate_signatured_type_table (objfile); Doug> + } Doug> if (dwarf2_die_debug) Doug> fprintf_unfiltered (gdb_stdlog, "Reading signatured types for %s:\n", Doug> - bfd_get_filename (abfd)); Doug> + bfd_get_filename (objfile->obfd)); The code uses abfd, but the debugging print uses objfile->obfd. If this is intentional, I think it deserves a clarifying comment. Doug> + /* FIXME: Why do ref attributes use DW_ADDR instead of DW_UNSND? */ Doug> + /* FIXME: Why do ref attributes use DW_ADDR instead of DW_UNSND? */ IIRC you fixed these already. Doug> +static struct bfd * Doug> +try_open_dwo_file (const char *file_name) Doug> +{ Doug> + bfd *sym_bfd; [...] I couldn't find any code to close these BFDs. I think it may be an oversight in free_dwo_file. Also, I wonder whether this needs special code for the case where the underlying object file is modified. Tom