From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106375 invoked by alias); 19 Jul 2018 19:07:26 -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 105337 invoked by uid 89); 19 Jul 2018 19:07:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=liked X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Jul 2018 19:07:24 +0000 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B942B9C0AC; Thu, 19 Jul 2018 19:07:23 +0000 (UTC) Received: from pinnacle.lan (ovpn-116-191.phx2.redhat.com [10.3.116.191]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 81011308BDAC; Thu, 19 Jul 2018 19:07:23 +0000 (UTC) Date: Thu, 19 Jul 2018 19:07:00 -0000 From: Kevin Buettner To: Simon Marchi Cc: gdb-patches@sourceware.org, Simon Marchi Subject: Re: [PATCH 0/8] Non-contiguous address range support Message-ID: <20180719120722.1ad62f10@pinnacle.lan> In-Reply-To: <009e5f0b06acafca3b778f0900f5df56@polymtl.ca> References: <20180625233239.49dc52ea@pinnacle.lan> <3b4f3bab-8f30-d878-09f0-0d9c60ba4583@ericsson.com> <20180716190036.3df0b4f2@pinnacle.lan> <009e5f0b06acafca3b778f0900f5df56@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00587.txt.bz2 On Thu, 19 Jul 2018 11:55:48 -0400 Simon Marchi wrote: > On 2018-07-16 22:00, Kevin Buettner wrote: > > Hi Simon, > > > > I haven't tried the simpler caching approach that you outline above. > > It seems like it should work and it would definitely make checking for > > whether or not something is in the cache simpler. > > > > I'll give it a try and run the test suite to see if there's a problem > > with > > doing it that way. > > > > Thanks, > > > > Kevin > > Just note that I don't have the complete picture yet. If the block > range information is necessary for some other reason, then it would make > sense to use it as well for that cache. I didn't want to send you on a > long side-quest for nothing! Hi Simon, The block range information is still required for several other reasons. One obvious case is that we need to iterate through the ranges for displaying disassembly. However, I really liked your suggestion because we can retain the simple test for determining whether or not PC is in the cache: if (mapped_pc >= cache_pc_function_low && mapped_pc < cache_pc_function_high && section == cache_pc_function_section) goto return_cached_value; I've posted a replacement for patch 3/8 which uses your approach. Note that the block range information is still used within that patch for determining the low and high addresses for the cache. What's not in that patch is the removal of block_contains_pc which was added in patch 1/8. The only caller of this function was in my earlier patch for find_pc_partial_function (in 3/8). It's no longer needed. I'm guessing that you'll have some suggestions which will require a v2 patch series. I'll wait to show the removal of block_contains_pc until that time. Thanks for looking at this... Kevin