From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72804 invoked by alias); 1 Aug 2018 01:36:13 -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 72795 invoked by uid 89); 1 Aug 2018 01:36:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=ton, savings, HX-MS-Exchange-CrossTenant-OriginalArrivalTime:Aug, UD:dwarf2read.c X-HELO: sessmg22.ericsson.net Received: from sessmg22.ericsson.net (HELO sessmg22.ericsson.net) (193.180.251.58) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Aug 2018 01:36:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533087367; 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=Y+fZ7QLSga3HvvZBItgK1C5mD9waBF6lz9frKcAffF8=; b=Ybk8fpEn6T/ujPOAbldiHLdk/3vrTu38AWaMnDfPlzWmRVoyBim6Rjr7FKFF5Irn 0ALhtpzJHvslhesFAdgAEshaDko8OgP9Ns66JCEyS/0c9UKD4bj6upDcvpUoJRph IQYdN7kdRSpu3kVR4bKl2JYMY/2XNjvP0dcKzUPx7gM=; Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 10.F0.31169.78E016B5; Wed, 1 Aug 2018 03:36:07 +0200 (CEST) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB502.ericsson.se (153.88.183.163) 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:36:06 +0200 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (153.88.183.157) 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 via Frontend Transport; Wed, 1 Aug 2018 03:36:06 +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=PSYipbPumn7zNyCbjqV1Srforu4dxH1oG32UVrTFQeo=; b=cFwnF71Pr3i18G5jpq6TpVEqmVRmm4cUX8c7HSbECsM1Sm4X1efa6NlV0ZIWPF9pXN1PDgyL+/jsj5G7E2gLIDGKYFpYLqcoZU/C36yImN2rFcutxl0285x+ziZ7qQPrasW4bXY2ezXZJ9Lu7W+IN6JMABaAhP+LwQi4QCgz5XA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from [10.0.0.110] (192.222.164.54) by BYAPR15MB2390.namprd15.prod.outlook.com (2603:10b6:a02:8c::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.14; Wed, 1 Aug 2018 01:36:02 +0000 Subject: Re: [PATCH 1/8] Add block range data structure for blocks with non-contiguous address ranges To: Kevin Buettner , References: <20180625233239.49dc52ea@pinnacle.lan> <20180625234210.1dbf3a9a@pinnacle.lan> From: Simon Marchi Message-ID: <45fb2e70-3924-b89b-0777-758c5e2715a7@ericsson.com> Date: Wed, 01 Aug 2018 01:36: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: <20180625234210.1dbf3a9a@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/msg00001.txt.bz2 On 2018-06-26 02:42 AM, Kevin Buettner wrote: > This patch does the following: > > - Introduces a block range data structure which is accessed via > a new field in struct block. > - Defines several macros for accessing block ranges. > - Defines a new function, make_blockrange, which is responsible for > creating the new data structure. > - Defines a predicate (function) which checks to see if an address > is present in a block. > > It should be noted that some support for non-contiguous ranges already > existed in GDB in the form of blockvector addrmaps. This support > allowed GDB to quickly find a block containing a particular address > even when the block consists of non-contiguous addresses. See > find_block_in_blockvector() in block.c, dwarf2_record_block_ranges() > in dwarf2read.c, and record_block_range() in buildsym.c. > > Addrmaps do not provide a convenient way to examine address ranges > associated with a particular block. This data structure (and its > interface) is set up for quickly finding the value (which in this case > is a block) associated with a particular address. The interface > does not include a method for doing a reverse mapping from blocks to > addresses. A linear time mapping might be attempted via use of the > addrmap's foreach method, but this is not as straightforward as it > might first appear due to the fact that blocks corresponding to inline > function instances and lexical blocks w/ variables end up getting > interspersed in in the set of transitions. > > Note: If this approach is deemed to be too expensive in terms of > space, an alternate approach might be to attempt the linear time > mapping noted above. find_pc_partial_function() needs to be able to > quickly know whether there are discontiguous ranges (for determining > cache validity), so a flag for this property would have to be added to > struct block. Also integral to this set of changes is the concept of > an "entry pc" which might be different than the block's start address. > An entry_pc field would also need to be added to struct block. This > does not result in any space savings in struct block though since the > space for the flag and entry_pc use more space than the blockranges > struct pointer that I've added. There would, however, be some space > savings due to the fact that the new data structures that I've added > for this patch would not need to be allocated. (I happen to like the > approach I've come up with, but I wanted to mention another possibility > just in case someone does not.) I assume the impact won't be too big (there probably isn't a ton of ranges per block), but some actual data would be interesting. Just two nits below, otherwise it LGTM. > @@ -807,3 +822,27 @@ block_find_non_opaque_type_preferred (struct symbol *sym, void *data) > *best = sym; > return 0; > } > + > +/* See block.h. */ > + > +struct blockranges * > +make_blockranges (struct objfile * objfile, Spurious space after the *. > @@ -322,4 +401,9 @@ extern int block_find_non_opaque_type_preferred (struct symbol *sym, > (sym) != NULL; \ > (sym) = block_iter_match_next ((name), &(iter))) > > +/* Given a vector of pairs, allocate and build an obstack allocated > + blockranges struct for a block. */ > +struct blockranges *make_blockranges (struct objfile *objfile, > + std::vector> &); Can you please name the second parameter, and make it const? Thanks, Simon