From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49208 invoked by alias); 1 Aug 2018 02:28:09 -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 49196 invoked by uid 89); 1 Aug 2018 02:28:08 -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=examined, discrimination 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 02:28:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533090485; 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=6X8HGaIvaULhMDAb57Nk2NOfVSrBrciWED04tmLYIOU=; b=IuKhko3flQLf4SzAPz7EySvuHIx0thAEPLHWwiVGCXKxjAzA2+m/YNb6Lz+/+4/g UmUlOek+qcLTVulXoyuke5dQ5Tv7Cfj2RHkxMkuUigk/0mQVEL+QbBhnRNTmTgFg w4GImCgXqO1HQBfgMGx9uLtH1zTBqs1az+oRQraLofk=; Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 10.87.22978.5BA116B5; Wed, 1 Aug 2018 04:28:05 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) 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; Wed, 1 Aug 2018 04:28:04 +0200 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (153.88.183.157) 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 via Frontend Transport; Wed, 1 Aug 2018 04:28:04 +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=ilxJ2yRlT5H7s0JyObZ9gjhX3TJtN2VCkooi+8WLtsA=; b=TBCoAsagMC5mu5TyBs0W+3b/T0URwquFhoeqdkq0t+ZhUUiEBxY/JUBaP6DTtQ+MvIaeM7f5+Q2fMFCeGRti+HQewaMnJzLB1GyFL6So29zcOS14loTnsHbT6N+YJt3oJP0yFFexEbWXGrBpPVOu6I7hUs9fOcdSVxgN2x0GLXI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from [10.0.0.110] (192.222.164.54) by DM6PR15MB2393.namprd15.prod.outlook.com (2603:10b6:5:8d::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.15; Wed, 1 Aug 2018 02:28:00 +0000 Subject: Re: [PATCH 6/8] Use BLOCK_ENTRY_PC to find function entry pc in infrun.c To: Kevin Buettner , References: <20180625233239.49dc52ea@pinnacle.lan> <20180625235326.2aa421f2@pinnacle.lan> From: Simon Marchi Message-ID: <187e47b4-64b5-33b3-8fb0-207a0aa24768@ericsson.com> Date: Wed, 01 Aug 2018 02:28: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: <20180625235326.2aa421f2@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/msg00007.txt.bz2 On 2018-06-26 02:53 AM, Kevin Buettner wrote: > find_pc_partial_function() still returns the lowest and highest address > of a function even when that function contains non-contiguous ranges. > In cases where greater discrimination is required, the BLOCK parameter > may be examined to determine the actual entry PC. > > This patch uses the BLOCK return value from find_pc_partial_function() > to obtain the entry PC. If no block is found - which can happen when > only minimal symbols are available - then the start address provided > by find_pc_partial_function() will still be used (as before). This one looks good to me, given how the stop_func_start field seems to be used. From what I understand, it is used as the entry point of the function, therefore BLOCK_ENTRY_PC seems appropriate. > @@ -4297,10 +4297,20 @@ fill_in_stop_func (struct gdbarch *gdbarch, > { > if (!ecs->stop_func_filled_in) > { > + const struct block *block; > + > /* Don't care about return value; stop_func_start and stop_func_name > will both be 0 if it doesn't work. */ > find_pc_partial_function (stop_pc, &ecs->stop_func_name, > - &ecs->stop_func_start, &ecs->stop_func_end); > + &ecs->stop_func_start, &ecs->stop_func_end, > + &block); > + > + /* If a block is returned, prefer the block's entry point instead of > + the lowest address of the block - these aren't necessarily the > + same. */ > + if (block) block != nullptr Simon