From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16295 invoked by alias); 22 Jun 2012 20:51:58 -0000 Received: (qmail 16287 invoked by uid 22791); 22 Jun 2012 20:51:57 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_EG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vb0-f41.google.com (HELO mail-vb0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 22 Jun 2012 20:51:44 +0000 Received: by vbkv13 with SMTP id v13so1364532vbk.0 for ; Fri, 22 Jun 2012 13:51:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=PgZnxDVVVqrljQcVASpuM4IYzR4I7jh8Yi3IJJ0koio=; b=jXyQMT4h0TGdSiH8lXG5unDDJq81ug+lfxrfkJFfB6K3VC0t5ivGyJTgmsd1EhinHl CtowDDOiLIbTYuDOaYRT/GcaHZkplZtoH3bQK7s1ZLVRtgWI2tl7hNi9wnqqka8/rXoa p/cpb67mOu2TVeQeZXJz2uHldP3xA+kQhOy/0bPKECHAJiPzOJzDb9FM8Hp9kd6GLnT7 35lkuX8v6WE1ERvgx7ktSNyvYav8s00zzUh+x0wCTBQH37VDViNpLiUXbIYe7YcSFMyo Am+vAGtfhjdBRpDZo2htPDTsqD21Tn9kX95T5FXiLW+jMJokQnIvklUu33Tusvd1PCPn CLsQ== Received: by 10.52.95.225 with SMTP id dn1mr1440985vdb.99.1340398301365; Fri, 22 Jun 2012 13:51:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.225 with SMTP id dn1mr1440977vdb.99.1340398301246; Fri, 22 Jun 2012 13:51:41 -0700 (PDT) Received: by 10.52.92.242 with HTTP; Fri, 22 Jun 2012 13:51:41 -0700 (PDT) In-Reply-To: <20120622193539.GA7344@host2.jankratochvil.net> References: <20120605011446.670FD1E123B@ruffy2.mtv.corp.google.com> <20120622193539.GA7344@host2.jankratochvil.net> Date: Fri, 22 Jun 2012 20:51:00 -0000 Message-ID: Subject: Re: [RFA] Fix inconsistency in blockvector addrmap vs non-addrmap handling From: Doug Evans To: Jan Kratochvil Cc: gdb-patches@sourceware.org, tromey@redhat.com, palves@redhat.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQk64J16GORmgEAv+g8pH92q9+PaHXElblbYT+RQxdgovPOAW+X/tsej+pNQ6p0gGBnFDYadPPuA60H/QdjrHfK5VCa3Ymwsj3woCWHP+WEemcMr6VVrdjKo4CN78umsQnyNYLYbesNfglPjbDXeHVTk6MBVHi9xrONgNFSM54Mszi8APfzAS88uB0gvwHXzGiopyFo6 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/msg00738.txt.bz2 On Fri, Jun 22, 2012 at 12:35 PM, Jan Kratochvil wrote: > On Tue, 05 Jun 2012 03:14:46 +0200, Doug Evans wrote: >> --- buildsym.c =A0 =A0 =A0 =A029 May 2012 20:23:17 -0000 =A0 =A0 =A01.97 >> +++ buildsym.c =A0 =A0 =A0 =A05 Jun 2012 00:26:01 -0000 >> @@ -1024,8 +1027,15 @@ end_symtab (CORE_ADDR end_addr, struct o >> =A0 =A0 =A0{ >> =A0 =A0 =A0 =A0/* Define the STATIC_BLOCK & GLOBAL_BLOCK, and build the >> =A0 =A0 =A0 =A0 =A0 blockvector. =A0*/ >> - =A0 =A0 =A0finish_block (0, &file_symbols, 0, last_source_start_addr, >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end_addr, objfile); >> + =A0 =A0 =A0struct block *static_block; >> + >> + =A0 =A0 =A0static_block =3D finish_block (0, &file_symbols, 0, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0last_so= urce_start_addr, end_addr, >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0objfile= ); >> + =A0 =A0 =A0/* Mark the range of the static block so that if we end up = using >> + =A0 =A0 =A0blockvector.map then find_block_in_blockvector behaves iden= tically >> + =A0 =A0 =A0regardless of whether the addrmap is present. =A0*/ >> + =A0 =A0 =A0record_block_range (static_block, last_source_start_addr, e= nd_addr - 1); > > On IRC Doug made a note: > =A0 =A0 =A0 =A0Arguably the second is the better fix but it's still a hac= k as > =A0 =A0 =A0 =A0addrmaps are intended to handle discontiguous symtabs and = this defeats > =A0 =A0 =A0 =A0that. > > Where "the first fix" was: > =A0 =A0 =A0 =A0[RFA] Fix gdb segv in dw2_find_pc_sect_symtab > =A0 =A0 =A0 =A0http://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 th= ere > a problem? > > >> =A0 =A0 =A0 =A0finish_block_internal (0, &global_symbols, 0, last_source= _start_addr, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end_addr, objfile= , 1); >> =A0 =A0 =A0 =A0blockvector =3D make_blockvector (objfile); With some work that could be made to work. But remember that the static block (or global block) doesn't exist until the call to end_symtab, and, barring even more work, you need to get the range into pending_addrmap before the call to make_blockvector where pending_addrmap is turned into a fixed addrmap.