From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34504 invoked by alias); 22 Aug 2018 16:57: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 34486 invoked by uid 89); 22 Aug 2018 16:57:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= 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; Wed, 22 Aug 2018 16:57:23 +0000 Received: from smtp.corp.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5F92C85550 for ; Wed, 22 Aug 2018 16:57:22 +0000 (UTC) Received: from pinnacle.lan (ovpn-116-27.phx2.redhat.com [10.3.116.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3BDCE30912F4 for ; Wed, 22 Aug 2018 16:57:22 +0000 (UTC) Date: Wed, 22 Aug 2018 16:57:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: [PATCH v4 0/8] Non-contiguous address range support Message-ID: <20180822095721.3e298051@pinnacle.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00541.txt.bz2 This is version 4 of an eight part patch series which adds further support for non-contiguous address ranges to GDB. This v4 series addresses concerns from Simon Marchi and Pedro Alves. Only parts 3, 6, and 8 have changed since v3. The v3 series had been rebased against more recent (current at time of posting) sources. In the v2 series, I addressed the concerns from Simon Marchi's review of the v1 patch set. I also changed my mind about how return values *ADDRESS and *ENDADDR ought to be set for find_pc_partial_function. I 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...