From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18341 invoked by alias); 22 Jun 2012 19:36:04 -0000 Received: (qmail 18159 invoked by uid 22791); 22 Jun 2012 19:36:03 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_EG,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; Fri, 22 Jun 2012 19:35:46 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5MJZixF003540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jun 2012 15:35:44 -0400 Received: from host2.jankratochvil.net (ovpn-116-33.ams2.redhat.com [10.36.116.33]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q5MJZe7G019822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 22 Jun 2012 15:35:42 -0400 Date: Fri, 22 Jun 2012 19:36: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: <20120622193539.GA7344@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/msg00731.txt.bz2 On Tue, 05 Jun 2012 03:14:46 +0200, Doug Evans wrote: > --- 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); On IRC Doug made a note: Arguably the second is the better fix but it's still a hack as addrmaps are intended to handle discontiguous symtabs and this defeats that. Where "the first fix" was: [RFA] Fix gdb segv in dw2_find_pc_sect_symtab http://sourceware.org/ml/gdb-patches/2012-05/msg00958.html I think the right way is to call dwarf2_record_block_ranges for DW_AT_compilation_unit but I haven't tried to write such patch yet, is there a problem? > finish_block_internal (0, &global_symbols, 0, last_source_start_addr, > end_addr, objfile, 1); > blockvector = make_blockvector (objfile); Thanks, Jan