From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90969 invoked by alias); 21 Aug 2018 16:29:50 -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 90888 invoked by uid 89); 21 Aug 2018 16:29:47 -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=motivated, uncommon 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; Tue, 21 Aug 2018 16:29:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1534868983; 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=mTaPDZwJXvDT2OoaAK3swp+w7TOW7UcB8D7P6FDU4zM=; b=dbQ4XFBqHeUWzucJBQbQW6YcVEUnQSrHmNQV0vcgmrmhrXgrDqhhnfM1Eqp4nsLF dulPueEOL/LExoI/uuRZDnUX6d8+GzQFDY+mBFv7hw+ZbrVgN1NlW0nEvnQCNV1j 1qN3UmVWckkkGXTO+PgrFnZAMC6m6qJCqeBtM1DWoa8=; Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CE.D1.05037.6FD3C7B5; Tue, 21 Aug 2018 18:29:43 +0200 (CEST) Received: from ESESSMB501.ericsson.se (153.88.183.162) 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; Tue, 21 Aug 2018 18:29:42 +0200 Received: from NAM05-BY2-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; Tue, 21 Aug 2018 18:29:42 +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=6RsnyFekfozW2GxTfl8/wFV99voyGnecWWv2YV1IhSQ=; b=iW7p3pVrrxja3Gut8r9MO56uE4DLxIPOkoi/6/RZxYra1SN4xKeqdSVAWOLSosT1CFPKAPMPZbYuArs4g6kDaFXjShL87ZlirArrCXjCEkLgpBHw03gw+KW/7CJSRZZt+vYPbU/YnUEDY5AF4dFrWB72Y5yw/X3PXBjiix5jPdY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from [142.133.61.8] (192.75.88.130) by SN6PR15MB2399.namprd15.prod.outlook.com (2603:10b6:805:24::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.20; Tue, 21 Aug 2018 16:29:39 +0000 Subject: Re: [PATCH v3 0/8] Non-contiguous address range support To: Kevin Buettner , References: <20180820152512.671a7dc7@pinnacle.lan> From: Simon Marchi Message-ID: <753f7788-c185-265b-133b-041c83c055d5@ericsson.com> Date: Tue, 21 Aug 2018 16:29: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: <20180820152512.671a7dc7@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/msg00497.txt.bz2 On 2018-08-20 06:25 PM, Kevin Buettner wrote: > This is version 3 of an eight part patch series which adds further > support for non-contiguous address ranges to GDB. > > This v3 series has been rebased against more recent (current at time > of posting) sources. > > In the v2 series, I've addressed the concerns from Simon Marchi's > review of the v1 patch set. I've also changed my mind about how > return values *ADDRESS and *ENDADDR ought to be set for > find_pc_partial_function. I'll discuss this matter in the remarks > preceding the relevant patches. > > Everything below this point was copy/pasted from the introductory > message for the v1 patch set... > > 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, Thanks for the v3, it was trivial to apply on today's master. This looks good, I have no further comments than what I have already sent. Simon