From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7187 invoked by alias); 5 Jun 2012 01:15:02 -0000 Received: (qmail 7081 invoked by uid 22791); 5 Jun 2012 01:15:01 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-fa0-f73.google.com (HELO mail-fa0-f73.google.com) (209.85.161.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Jun 2012 01:14:48 +0000 Received: by faas14 with SMTP id s14so342062faa.0 for ; Mon, 04 Jun 2012 18:14:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=to:subject:message-id:date:from:x-gm-message-state; bh=YGFdCnMt4FR0Ay1w3U2trxaaBhu6ypRCpXdv58A54TI=; b=PXJYSXHmRdorWz3Y+NqH/0wFXHON8TH6AkfcMNMPD+7v9PnIIl85jSisYMCHglAXOZ 48NutRzcJ9IYs8N6hYYIFeFLL9UVNYSa+myoewjQ7jThuFLgFDpUJw7MnaLr8nCYeZ0g Qo1Bs/r2SM3v11d75gZx6LUssciJSkiqJCVEqunp+IZGc2l1YLVgLHeGqTIc3uUoBCIs e+v2+VUfv0z944ivAyC6an9WYvjapaKSaLPCexN++APR/h0W5N+FuyVrUeh4rZOYNWYI pVz/eqPteOTSrNeeJBmwbLZH7V1YCQJU3/DML/zDd4Q8LTNkL0Ow8rNuOjM+xJykcotB bc0A== Received: by 10.14.119.205 with SMTP id n53mr4435709eeh.11.1338858887355; Mon, 04 Jun 2012 18:14:47 -0700 (PDT) Received: by 10.14.119.205 with SMTP id n53mr4435703eeh.11.1338858887274; Mon, 04 Jun 2012 18:14:47 -0700 (PDT) Received: from hpza9.eem.corp.google.com ([74.125.121.33]) by gmr-mx.google.com with ESMTPS id b15si92091een.0.2012.06.04.18.14.47 (version=TLSv1/SSLv3 cipher=AES128-SHA); Mon, 04 Jun 2012 18:14:47 -0700 (PDT) Received: from ruffy2.mtv.corp.google.com (ruffy2.mtv.corp.google.com [172.18.110.129]) by hpza9.eem.corp.google.com (Postfix) with ESMTP id 168015C0050; Mon, 4 Jun 2012 18:14:47 -0700 (PDT) Received: by ruffy2.mtv.corp.google.com (Postfix, from userid 67641) id 670FD1E123B; Mon, 4 Jun 2012 18:14:46 -0700 (PDT) To: gdb-patches@sourceware.org, tromey@redhat.com, palves@redhat.com Subject: [RFA] Fix inconsistency in blockvector addrmap vs non-addrmap handling Message-Id: <20120605011446.670FD1E123B@ruffy2.mtv.corp.google.com> Date: Tue, 05 Jun 2012 01:15:00 -0000 From: dje@google.com (Doug Evans) X-Gm-Message-State: ALoCoQkiJgOppRSDVcakKQMrpl6WJeSKBPRQw27CuShSejDqMZNzgDIar0PSBr6/M76fbiLVD/EJ/BDrgLydw9hobJ28qkmj/8RYAmhVaf2dy0KzOOGqzFfAbu68dZBzSFDKMqj8ly/p/plf+LgqWEFTsmWjiAq+fg== 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/msg00109.txt.bz2 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?). 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? 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);