From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106184 invoked by alias); 1 Aug 2018 01:41:10 -0000 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 Received: (qmail 105719 invoked by uid 89); 1 Aug 2018 01:41:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3 autolearn=ham version=3.3.2 spammy= X-HELO: sesbmg22.ericsson.net Received: from sesbmg22.ericsson.net (HELO sesbmg22.ericsson.net) (193.180.251.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Aug 2018 01:41:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533087666; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WJwvkMvLDe/bUZ2L+P3pJ1LRdyFTPmrFbXRqJsHkUZY=; b=f7lSDOiw77AtoP5LEK6AYYgqBocg1iPHuUsZAL2OUN5jArkItYmaIrjGPq2rQfiM POEK07DX5im13OU1lylkhdVehFAgQiOx+nNLVDstgC0Db0+muJZvUnhe2dtbtDAZ oaeMhXpcMu46TnlAramHQN9hOUAa5GSmdZ4SWrIYHrA=; Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C4.12.22978.2BF016B5; Wed, 1 Aug 2018 03:41:06 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 1 Aug 2018 03:41:03 +0200 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 1 Aug 2018 03:41:03 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ntqyaFPmr101ACj16FsNtsbyNHV3YenUqZdOEjTKIDk=; b=QgIUtQitPo7wC/ZXHX/GXjl1vgR40eXzfoqbPj2L2IN/1U1rRBp3nB/Wh+gumNsrNUUQsvIx5+AclLZO2Teijp5SqAmVCEKvi/7Cnf8ypR8ObOniMCZV+JCxfuemYQpx6rhcvE9B0Rk45hdX+xhDGvXBgwTlP1GsdCozN6V1zTo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from [10.0.0.110] (192.222.164.54) by BN7PR15MB2388.namprd15.prod.outlook.com (2603:10b6:406:8c::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.19; Wed, 1 Aug 2018 01:41:00 +0000 Subject: Re: [PATCH 2/8] Record explicit block ranges from dwarf2read.c To: Kevin Buettner , References: <20180625233239.49dc52ea@pinnacle.lan> <20180625234434.5c3913fa@pinnacle.lan> From: Simon Marchi Message-ID: Date: Wed, 01 Aug 2018 01:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180625234434.5c3913fa@pinnacle.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-Path: simon.marchi@ericsson.com Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00003.txt.bz2 On 2018-06-26 02:44 AM, Kevin Buettner wrote: > This change sets BLOCK_RANGES for the block under consideration by > calling make_blockranges(). This action is performed in > dwarf2_record_block_ranges(). > > It should be noted that dwarf2_record_block_ranges() already does some > recording of the range via a call to record_block_range(). The ranges > recorded in that fashion end up in the address map associated with the > blockvector for the compilation unit's symtab. Given an address, the > addrmap provides a fast way of finding the block containing that > address. The address map does not, however, provide a convenient way > of determining which address ranges make up a particular block. > > While reading a set of ranges, a vector of pairs is used to collect > the starting and ending addresses for each range in the block. Once > all of the ranges for a block have been collected, make_blockranges() > is called to fill in BLOCK_RANGES for the block. > > The ranges are stored for the block in the order that they're read > from the debug info. For DWARF, the starting address of the first > range of the block will be the entry pc in cases where DW_AT_entry_pc > is not present. (Well, that would ideally be the case. At the moment > DW_AT_entry_pc is not being handled.) > > gdb/ChangeLog: > > * dwarf2read.c (dwarf2_record_block_ranges): Fill in BLOCK_RANGES > for block. > --- > gdb/dwarf2read.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c > index 4ad0527..2f0f9b9 100644 > --- a/gdb/dwarf2read.c > +++ b/gdb/dwarf2read.c > @@ -14722,6 +14722,7 @@ dwarf2_record_block_ranges (struct die_info *die, struct block *block, > unsigned long offset = (DW_UNSND (attr) > + (need_ranges_base ? cu->ranges_base : 0)); > > + std::vector> blockvec; > dwarf2_ranges_process (offset, cu, > [&] (CORE_ADDR start, CORE_ADDR end) > { > @@ -14730,7 +14731,10 @@ dwarf2_record_block_ranges (struct die_info *die, struct block *block, > start = gdbarch_adjust_dwarf2_addr (gdbarch, start); > end = gdbarch_adjust_dwarf2_addr (gdbarch, end); > record_block_range (block, start, end - 1); > + blockvec.push_back (std::make_pair (start, end)); A real small nit, using blockvec.emplace_back (start, end); would avoid some unnecessary copying. Otherwise, it LGTM. Simon