From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11105 invoked by alias); 17 Jan 2013 17:53:27 -0000 Received: (qmail 11062 invoked by uid 22791); 17 Jan 2013 17:53:25 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ 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; Thu, 17 Jan 2013 17:52:42 +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 r0HHqf0k021680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Jan 2013 12:52:41 -0500 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 r0HHqdMx010087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Jan 2013 12:52:40 -0500 From: Tom Tromey To: Doug Evans Cc: gdb-patches@sourceware.org, ccoutant@google.com, saugustine@google.com Subject: Re: [RFA] Work around binutils/15021 References: Date: Thu, 17 Jan 2013 17:53:00 -0000 In-Reply-To: (Doug Evans's message of "Wed, 16 Jan 2013 15:21:29 -0800") Message-ID: <87ehhjd7dk.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.91 (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: 2013-01/txt/msg00369.txt.bz2 >>>>> "Doug" == Doug Evans writes: Doug> Regression tested with gdb-generated .gdb_index version 7 (by hacking the Doug> gdb-under-test to generate version 7), version 8, with dwz, and with gold. I think index version bumps require a documentation update and also a binutils patch. Doug> Work around binutils/15021 IIUC, the version bump is part of the workaround for the gold bug, right? The idea being that gold will generate version 7 indices, causing gdb to take the "inclusion" path. (I'm just trying to make sure I understand what is going on.) Doug> + This is also used to work around a difference between the way gold Doug> + generates .gdb_index version <=7 and the way gdb does. Arguably this Doug> + is a gold bug. To me it doesn't seem arguable, but I'm curious to know what the case is for it not being a gold bug. Doug> @@ -19634,7 +19660,7 @@ dwarf2_per_objfile_free (struct objfile Doug> for (ix = 0; ix < dwarf2_per_objfile->n_comp_units; ++ix) Doug> VEC_free (dwarf2_per_cu_ptr, Doug> - dwarf2_per_objfile->all_comp_units[ix]->s.imported_symtabs); Doug> + dwarf2_per_objfile->all_comp_units[ix]->imported_symtabs); If follow_die_sig can be called when one TU refers to another TU, then it seems like the TU could have a non-empty 'imported_symtabs', meaning that the loop here should also iterate over TUs. Tom