From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79650 invoked by alias); 21 Aug 2018 16:19:38 -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 79551 invoked by uid 89); 21 Aug 2018 16:19:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3 autolearn=ham version=3.3.2 spammy= 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; Tue, 21 Aug 2018 16:19:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1534868371; 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=kn9tIbDzG5kIEU+mR7IkPBIZjj1ojhkZjocuLO9tdVc=; b=Id9982PTZBd86CDdJ3kQpWCI3qWBtky//LUCJ0+epCS0WxOGFxUCV9UJ3K2M5ODG e03lcSqPg5loaTgufPcp2z4i4G0DYuitG0fdvYv6avV+m+2QOqnFZvoP3Y3UFh2a l6m+DI3RX3vME8mdzj9FdLuoQCog2tuv8AyIcWAmFNo=; Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F6.F8.26635.39B3C7B5; Tue, 21 Aug 2018 18:19:31 +0200 (CEST) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 21 Aug 2018 18:19:31 +0200 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) 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; Tue, 21 Aug 2018 18:19:31 +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=AENDyyMppMPZywRrnVhOUupHlQSXPRYzeoIAJ0Z2T4o=; b=LI/SDmocmXp8UCA4+6yPyCYuauggpUP61STU+hGUOcv9PENFdoGrG88s5y/aiIfrHIJYlEQPaOZCdIQ++115E2/NWfXMan2uSaVtb3PvezBH3FornO3NIWActyRWgPWg3xJCaAFll9KLFCAIFAeB1UCS4luSnFXBvUv2h6a7fjY= Received: from [142.133.61.8] (192.75.88.130) by BN7PR15MB2387.namprd15.prod.outlook.com (2603:10b6:406:8c::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.25; Tue, 21 Aug 2018 16:19:25 +0000 Subject: Re: [PATCH v3 6/8] Introduce find_pc_partial_entry_range and use it in infrun.c To: Kevin Buettner , References: <20180820152512.671a7dc7@pinnacle.lan> <20180820154546.5a9f9c6f@pinnacle.lan> From: Simon Marchi Message-ID: Date: Tue, 21 Aug 2018 16:19: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: <20180820154546.5a9f9c6f@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) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00495.txt.bz2 On 2018-08-20 06:45 PM, Kevin Buettner wrote: > An earlier version of this patch used the returned block in conjunction > with BLOCK_ENTRY_PC to set stop_func_start in fill_in_stop_func() in > infrun.c. While I think this was the correct thing to do, changes > to find_inferior_partial_function could potentially end up with > stop_func_end < stop_func_start, which is definitely wrong. For > this case, we want to set both stop_func_start and stop_func_end > to the start and end of the range containing the function's entry > pc. > > I think that this functionality will be useful in many other places > too - it probably ought to be used in all of the various prologue > analyzers in GDB. > > The change to infrun.c was simple: the call to find_pc_partial_function > was replaced with a call to find_pc_partial_entry_range. The difference > between these two functions is that find_pc_partial_entry_function > will (potentially) return the start and end address corresponding to > the range in which PC is found, but find_pc_partial_entry_range > will (again, potentially) return the start and end address of the > range containing the entry pc. find_pc_partial_function has the > property that *ADDRESS <= PC < *ENDADDR. This condition does not > necessarily hold for the outputs of find_pc_partial_entry_range. > > It should be noted that for functions which contain only a single > range, the outputs of find_pc_partial_{function,entry_range} are > identical. > > I think it might happen that find_pc_partial_entry_range will come > to be used in place of many of the calls to find_pc_partial_function > within GDB. Care must be taken in making this change, however, since > some of this code depends on the *ADDRESS <= PC < *ENDADDR property. This LGTM. I just find the naming of all these finc_pc_* funtions confusing, like what does the "partial" mean in "find_pc_partial_function"? Why does the new function name not include "function"? I don't really have a better alternative to suggest, but if there's a logic behind the new name I'd like to know it so I understand the naming scheme better. > diff --git a/gdb/infrun.c b/gdb/infrun.c > index b25d745..fb72880 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -4285,11 +4285,12 @@ fill_in_stop_func (struct gdbarch *gdbarch, > { > if (!ecs->stop_func_filled_in) > { > + This looks like an unwanted change. Simon