From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21168 invoked by alias); 5 Jun 2012 15:06:50 -0000 Received: (qmail 21154 invoked by uid 22791); 5 Jun 2012 15:06:48 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,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; Tue, 05 Jun 2012 15:06:31 +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 q55F6Uvk006067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jun 2012 11:06:30 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q55F6S0f032626; Tue, 5 Jun 2012 11:06:29 -0400 Message-ID: <4FCE2074.2060001@redhat.com> Date: Tue, 05 Jun 2012 15:06:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Doug Evans CC: gdb-patches@sourceware.org, tromey@redhat.com Subject: Re: [RFA] Fix inconsistency in blockvector addrmap vs non-addrmap handling References: <20120605011446.670FD1E123B@ruffy2.mtv.corp.google.com> In-Reply-To: <20120605011446.670FD1E123B@ruffy2.mtv.corp.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-06/txt/msg00131.txt.bz2 On 06/05/2012 02:14 AM, Doug Evans wrote: > Hi. > > I was seeing the assert in dw2_find_pc_sect_psymtab trigger > and traced it to the fact that when pending_addrmap_interesting gets > set blockvector.map is used instead of blockvector.block. > The difference is that blockvector.block contains entries for the global > and static blocks whereas pending_addrmap doesn't. > > This patch fixes this by making them consistent. > I suspect more work is necessary (e.g. can symtabs "overlap" even though > the individual pieces do not?). Yeah, I suppose it could be conceivable, say with __attribute__ section and/or linker scripts. > But I first want to fix the regression introduced by the change > to dw2_find_pc_sect_psymtab: There is more code in a symtab than is > documented by function and lexical block pc ranges (e.g. C++ method thunks). > > Regression tested on amd64-linux, and by verifying the assert no longer > triggers in the testcase I was using. > > Ok to commit? FWIW, looks fine to me, but I don't really know all the ins and outs of the symbol stuff. > > Note that this obviates the need for the patch in: > http://sourceware.org/ml/gdb-patches/2012-05/msg00958.html > > Also note that this accompanies this patch: > http://sourceware.org/ml/gdb-patches/2012-06/msg00105.html > > 2012-06-04 Doug Evans > > * buildsym.c (end_symtab): Add the range of the static block to > the pending addrmap. > > Index: buildsym.c > =================================================================== > RCS file: /cvs/src/src/gdb/buildsym.c,v > retrieving revision 1.97 > diff -u -p -r1.97 buildsym.c > --- buildsym.c 29 May 2012 20:23:17 -0000 1.97 > +++ buildsym.c 5 Jun 2012 00:26:01 -0000 > @@ -1024,8 +1027,15 @@ end_symtab (CORE_ADDR end_addr, struct o > { > /* Define the STATIC_BLOCK & GLOBAL_BLOCK, and build the > blockvector. */ > - finish_block (0, &file_symbols, 0, last_source_start_addr, > - end_addr, objfile); > + struct block *static_block; > + > + static_block = finish_block (0, &file_symbols, 0, > + last_source_start_addr, end_addr, > + objfile); > + /* Mark the range of the static block so that if we end up using > + blockvector.map then find_block_in_blockvector behaves identically > + regardless of whether the addrmap is present. */ > + record_block_range (static_block, last_source_start_addr, end_addr - 1); > finish_block_internal (0, &global_symbols, 0, last_source_start_addr, > end_addr, objfile, 1); > blockvector = make_blockvector (objfile); -- Pedro Alves