From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11759 invoked by alias); 28 Apr 2012 23:30:13 -0000 Received: (qmail 11736 invoked by uid 22791); 28 Apr 2012 23:30:11 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vb0-f41.google.com (HELO mail-vb0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 28 Apr 2012 23:29:58 +0000 Received: by vbbey12 with SMTP id ey12so1669831vbb.0 for ; Sat, 28 Apr 2012 16:29:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=AR2cu2/fYN0RgFiyyjCF0/P8Gr8KNhe41TQg4i5GPSY=; b=dgKlcGVv3QudeCH4nHJlr1YtzgY24fkB1JKRnBYxDxmB4awbxEk3kqxiUJ2EIDsuaR 6D6nF49xxzllQVRlraGa0IapcLdq5UIjchSDJ6E5MmfsDKuRijXQ0qjSpN+KxEiVC8BF hSsOF6G7p6sxZjcUwNh+LDqvDGzvBP3ux0kRjc2WEbtV3EyeF6znmlLw+47QeCRIivZl KnaMPPyuMYnyywBp+hlHaAq0rH+3/ud04e0odY+9ZeUq0RHERzKdP+HvcQEBR59oubq3 E1NBf5o0AN+4SBKOrF8C+Te3G9NVLDG70wFiHdnFqiym62K30deACy9krtahpJrKGMvb T9sA== Received: by 10.220.40.73 with SMTP id j9mr1960930vce.63.1335655796993; Sat, 28 Apr 2012 16:29:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.40.73 with SMTP id j9mr1960921vce.63.1335655796893; Sat, 28 Apr 2012 16:29:56 -0700 (PDT) Received: by 10.52.165.2 with HTTP; Sat, 28 Apr 2012 16:29:56 -0700 (PDT) In-Reply-To: <87397p3usu.fsf@fleche.redhat.com> References: <20120418185738.277DB2461AF@ruffy.mtv.corp.google.com> <87397p3usu.fsf@fleche.redhat.com> Date: Sat, 28 Apr 2012 23:59:00 -0000 Message-ID: Subject: Re: [RFA 3/3] Initial Fission support, the actual Fission stuff From: Doug Evans To: Tom Tromey Cc: gdb-patches@sourceware.org, ccoutant@google.com, saugustine@google.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnfOiYPD3fye0tZz5IsMZalYm7QFM1Fmzcr1x2ihHoJ9yQ4CN+alnbMjjJCWeH6kdC6wE8PteWmQfZiZ2ZJRzAj5eiWhoi9FBfe+VWsea9aAY5OoGv60m/R1ZRh1FNtf6kD9u0shcl0Wu59HPn+fLYQCl/Ulg== X-IsSubscribed: yes 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/msg01056.txt.bz2 On Fri, Apr 27, 2012 at 11:15 AM, Tom Tromey wrote: >>>>>> "Doug" =3D=3D Doug Evans writes: > > Doug> =A0 * symfile.h (dwarf2_debug_sections): New members addr, ref. > > I think you have to update xcoffread.c as well. Righto. > Doug> + =A0struct 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. Yeah, done. > Doug> + =A0 =A0 =A0/* We can't set abfd until now because the section may= be empty or > Doug> + =A0not present, in which case section->asection will be NULL. =A0= */ > Doug> + =A0 =A0 =A0abfd =3D section->asection->owner; > Doug> + > Doug> =A0 =A0 =A0 =A0if (types_htab =3D=3D NULL) > Doug> - types_htab =3D allocate_signatured_type_table (objfile); > Doug> + { > Doug> + =A0 if (dwo_file) > Doug> + =A0 =A0 types_htab =3D allocate_dwo_unit_table (objfile); > Doug> + =A0 else > Doug> + =A0 =A0 types_htab =3D allocate_signatured_type_table (objfile); > Doug> + } > > Doug> =A0 =A0 =A0 =A0if (dwarf2_die_debug) > Doug> =A0 fprintf_unfiltered (gdb_stdlog, "Reading signatured types for %= s:\n", > Doug> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bfd_get_filename (abfd)); > Doug> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 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. Done. > Doug> + =A0 /* FIXME: Why do ref attributes use DW_ADDR instead of DW_UNS= ND? =A0*/ > > Doug> + =A0 /* FIXME: Why do ref attributes use DW_ADDR instead of DW_UNS= ND? =A0*/ > > IIRC you fixed these already. Righto, removed. > Doug> +static struct bfd * > Doug> +try_open_dwo_file (const char *file_name) > Doug> +{ > Doug> + =A0bfd *sym_bfd; > [...] > > I couldn't find any code to close these BFDs. > I think it may be an oversight in free_dwo_file. Indeed. > Also, I wonder whether this needs special code for the case where the > underlying object file is modified. That will require some API enhancements to the file readers (there could be an arbitrary number of such files, and I don't want symfile.c to have to know about them). I'm going to submit that as a separate patch. As discussed off list, I've committed the patches to date. Regression tested without fission. A few failures remain with -gfission. I still need a NEWS entry as well. That will come with the followup patch.