From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15330 invoked by alias); 8 Jun 2013 16:04:30 -0000 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 Received: (qmail 15320 invoked by uid 89); 8 Jun 2013 16:04:30 -0000 X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,TW_DW autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sat, 08 Jun 2013 16:04:29 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r58G4Rvf004461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Jun 2013 12:04:27 -0400 Received: from host2.jankratochvil.net (ovpn-116-66.ams2.redhat.com [10.36.116.66]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r58G4LQ5027899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 8 Jun 2013 12:04:24 -0400 Date: Sun, 09 Jun 2013 17:09:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: gdb-patches@sourceware.org, tromey@redhat.com, ccoutant@google.com, saugustine@google.com, Jakub Jelinek Subject: Re: [RFA] Work around binutils/15021 Message-ID: <20130608160421.GA10141@host2.jankratochvil.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-06/txt/msg00191.txt.bz2 Hello Doug, On Thu, 17 Jan 2013 00:21:29 +0100, Doug Evans wrote: > + This is also used to work around a difference between the way gold > + generates .gdb_index version <=7 and the way gdb does. Arguably this > + is a gold bug. For symbols coming from TUs, gold records in the index > + the CU that includes the TU instead of the TU itself. This breaks > + dw2_lookup_symbol: It assumes that if the index says symbol X lives > + in CU/TU Y, then one need only expand Y and a subsequent lookup in Y > + will find X. Alas TUs live in their own symtab, so after expanding CU Y > + we need to look in TU Z to find X. Fortunately, this is akin to > + DW_TAG_imported_unit, so we just use the same mechanism: For > + .gdb_index version <=7 this also records the TUs that the CU referred > + to. Concurrently with this change gdb was modified to emit version 8 > + indices so we only pay a price for gold generated indices. */ what is the gold bug? According to the description I would expect from gold a line [773] C: 1 [no symbol information] but there is a line similar to what contains a gdb-produced index 7/8. [773] C: T0 [no symbol information] dwz currently supports at most version 7 so I am not sure if there is any change needed in dwz for version 8. Thanks, Jan echo 'void f() {}' >tu0.C;echo 'class C {} c; int main() {}' >tu.C;for i in tu0 tu;do g++ -c -o $i.o $i.C -Wall -g -fdebug-types-section;done;g++ -o tu tu0.o tu.o -Wall;ld.gold -o tugold tu0.o tu.o --gdb-index;cp tu tu7;~/redhat/gdb-test-gdbindex7/gdb-add-index ./tu7;cp tu tu8;gdb-add-index tu8 ==> tu0.C <== --- CU 0 void f() {} ==> tu.C <== --- CU 1 class C {} c; int main() {} readelf --debug-dump=gdb_index tu{7,8} # There is no difference in these ------------------------------------------------------------------------------ Contents of the .gdb_index section: Version {7,8} CU table: [ 0] 0x0 - 0x48 [ 1] 0x49 - 0xb1 TU table: [ 0] 0x0 0x25 e5fcb7a195b2f213 Address table: 00000000004005b0 00000000004005b6 0 00000000004005b8 00000000004005c3 1 Symbol table: [489] main: 1 [global function] [754] int: 1 [static type] [773] C: T0 [global type] [1010] c: 1 [global variable] [1013] f: 0 [global function] ------------------------------------------------------------------------------ readelf --debug-dump=gdb_index tugold ------------------------------------------------------------------------------ Contents of the .gdb_index section: Version 5 CU table: [ 0] 0x0 - 0x48 [ 1] 0x49 - 0xb1 TU table: [ 0] 0x0 0x25 e5fcb7a195b2f213 Address table: 00000000004000e8 00000000004000ee 0 00000000004000f0 00000000004000fb 1 Symbol table: [489] main: 1 [no symbol information] [754] int: 1 [no symbol information] [773] C: T0 [no symbol information] [1010] c: 1 [no symbol information] [1013] f: 0 [no symbol information] ------------------------------------------------------------------------------