From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121412 invoked by alias); 12 Jul 2018 19:12:35 -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 121381 invoked by uid 89); 12 Jul 2018 19:12:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.2 spammy=thinks, buettner, albeit, caching X-HELO: sesbmg23.ericsson.net Received: from sesbmg23.ericsson.net (HELO sesbmg23.ericsson.net) (193.180.251.37) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Jul 2018 19:12:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1531422749; 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=DxIkI1MlQODk5QQsa8WxqR0J3XIc5MY9/s+Vz+kFl+E=; b=F13jmIn6+uYwx8I1SwqQ08AjVBlHPEwpUvZ3xA0ktinOm69ZI039dUC4c8XMl5Vs nx3jc6twovpm4vcgg8+7j70crAMoIqAm+0EIbUhLXfX0qvB7TItGHZJ6xTj4VX0h AhDcD4njPXefw0sZJ4mToOGyCKW/uFz2IKD8BT0mq60=; Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C0.FF.25360.D18A74B5; Thu, 12 Jul 2018 21:12:29 +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; Thu, 12 Jul 2018 21:12:28 +0200 Received: from NAM01-BN3-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; Thu, 12 Jul 2018 21:12:28 +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=+NJLKdp8zL5NH/EzmDQJeuD1+Ii81+oQETkSWNkL774=; b=Hgbk7+dE+le/fkdKidDI71Ygr5bThZyYYpCSYh2I8WGueZU71dFIixEtt8sMfFy5VBlHQHI3iYuHR3WJw8qcbO855gZ/P2xMPe0yVPZdNeePDJuJCelvF/k2NsPQR9iw0ABRjvtniSk1V3Pf3wJNiGqwQOkPI7b3opr5k6CUC50= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from [142.133.61.147] (192.75.88.130) by SN6PR15MB2397.namprd15.prod.outlook.com (2603:10b6:805:24::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.17; Thu, 12 Jul 2018 19:12:26 +0000 Subject: Re: [PATCH 0/8] Non-contiguous address range support To: Kevin Buettner , References: <20180625233239.49dc52ea@pinnacle.lan> From: Simon Marchi Message-ID: <3b4f3bab-8f30-d878-09f0-0d9c60ba4583@ericsson.com> Date: Thu, 12 Jul 2018 19:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180625233239.49dc52ea@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-07/txt/msg00348.txt.bz2 On 2018-06-26 02:32 AM, Kevin Buettner wrote: > This eight part patch sequence adds (further) support for > non-contiguous address ranges to GDB. > > This sequence of patches was motivated by GCC bug 84550: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550 > > There is a test case posted to that bug along with some analysis of > the underlying problem. > > There is also a GDB bug for the same issue; it's 23021, but at the > moment, there is little there aside from a link to the GCC bug > mentioned above. But here's a link anyway: > > https://sourceware.org/bugzilla/show_bug.cgi?id=23021 > > A quick synopsis of the problem is as follows... > > Recent versions of gcc can generate code in which a function is split > into at least two non-contiguous address ranges. As I understand it, > the idea here is to separate code which gcc does not expect to execute > in normal operation from the rest of the code. Doing this may result > in better cache locality for the normal case. The generated code for > the example in GCC bug 84550 separated a call to abort() from the rest > of the code comprising the function. > > In the course of my investigation, I identified at least four > problems: > > 1) Stepping into a function from a function which occupies non-contiguous > address ranges does not always work. It was not uncommon to see the > program run to completion when attempting to do a step. > > 2) Setting a breakpoint on a function with non-contiguous address ranges > causes a breakpoint to be placed on more than one location. When a > breakpoint is set on the "cold" address range, this is almost certainly > incorrect. The breakpoint should instead be set only on code near the > entry point(s). > > 3) The disassemble command did not work correctly. E.g. here is what I > found during my analysis of 84550: > > (gdb) x/i 'main.cold.0' > 0x4010e0 : mov %rax,%rdi > (gdb) x/i main > 0x4011a0
: push %r12 > (gdb) disassemble main > Dump of assembler code for function main(): > 0x00000000004010e0 <+0>: mov %rax,%rdi > ... > [No addresses starting at 0x4011a0 are shown] > > 4) Display of addresses associated with the non-contiguous function are > confusing. E.g. in the above example, note that GDB thinks that > the address associated with main.cold.0 is , but that there's > also a minsym called main which is displayed as
. > > There are probably several other problems which are related those > identified above. > > I discovered that the stepping problem could be "fixed" by disabling > the find_pc_partial_function cache. This cache keeps track of the > most recent result (of calling find_pc_partial_function). If > find_pc_partial_function is called with an address which falls within > the cache range, then that's considered to be a cache hit and the most > recent result is returned. Obviously, this won't work correctly for > functions which occupy non-contiguous (disjoint) address ranges where > other functions might be placed in the gap. > > So one of the problems that needed to be solved was to make the > caching code work correctly. It is interesting to note that stepping > _did_ work when the cache was disabled. This is/was due to GDB > already having some (albeit incomplete) support for non-contiguous > addresses in the form of blockvector address maps. Code responsible > for mapping addresses to blocks (which form the lower levels of > find_pc_partial_function) handle this case correctly. > > To solve the problem of incorrect disassembly, we need to be able > to iterate over all of the ranges associated with a block. > > Finally, we need to distinguish between the entry pc and the lowest > address in a block. I discovered that this lack of distinction was > the cause of the remainder of the bugs including some which seemed to > be introduced by fixing the problems noted above. Once this > distinction is made, it will be straightforward to add full support for > DW_AT_entry_pc. I considered adding this support as part of this > patch series, but decided to wait until the community weighs in on my > work thus far... > Hi Kevin, I just started looking into this, but I already have a question, just for the sake of the discussion. After reading this description and the first few patches, it seems to me like one "cheap" way to fix the caching issue would be to record the contiguous portion of the address range instead of the low/high of the complete block. So if we have this: [0x100,0x110) function_a [0x110,0x120) function_b [0x120,0x130) function_a.cold When probing for pc = 0x104, we currently save: cache_pc_function_low = 0x100 cache_pc_function_high = 0x130 But instead we would save; cache_pc_function_low = 0x100 cache_pc_function_high = 0x110 I assume that the usage pattern of find_pc_partial_function is querying multiple times the same pc, or pc in increasing order (e.g. when disassembling). This modification wouldn't change the efficiency of the cache in these situations. Your solution of recording address ranges for blocks is more complete and probably necessary for other use cases, I am not questioning that, but I wanted to know if you had first tried a simpler solution similar to the above. Simon