From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31848 invoked by alias); 6 Jun 2012 15:54:34 -0000 Received: (qmail 31838 invoked by uid 22791); 6 Jun 2012 15:54:33 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,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; Wed, 06 Jun 2012 15:54:17 +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 q56FsGkk025913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jun 2012 11:54:16 -0400 Received: from host2.jankratochvil.net (ovpn-116-47.ams2.redhat.com [10.36.116.47]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q56FsBV3008641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 6 Jun 2012 11:54:14 -0400 Date: Wed, 06 Jun 2012 15:54:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: gdb-patches@sourceware.org, tromey@redhat.com, palves@redhat.com Subject: Re: [RFA] Fix inconsistency in blockvector addrmap vs non-addrmap handling Message-ID: <20120606155411.GA5691@host2.jankratochvil.net> References: <20120605011446.670FD1E123B@ruffy2.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120605011446.670FD1E123B@ruffy2.mtv.corp.google.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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-06/txt/msg00186.txt.bz2 On Tue, 05 Jun 2012 03:14:46 +0200, Doug Evans wrote: > 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); I am fine with the patch. FYI I would extend the comment a bit: /* 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. That means it returns this symtab even for addresses covered by compilation unit ranges but not belonging to any symbol in this symtab. STATIC_BLOCK is more inner than GLOBAL_BLOCK, this is the only reason why choose it for LAST_SOURCE_START_ADDR..END_ADDR. */ > blockvector = make_blockvector (objfile); Thanks, Jan