From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id 47706386F037 for ; Thu, 21 May 2020 07:50:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 47706386F037 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-475-iBP2HPwJOue-z0qkTb1Wbg-1; Thu, 21 May 2020 03:50:22 -0400 X-MC-Unique: iBP2HPwJOue-z0qkTb1Wbg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5303D8015D1 for ; Thu, 21 May 2020 07:50:21 +0000 (UTC) Received: from f31-4.lan (ovpn-115-18.phx2.redhat.com [10.3.115.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1ECB05C1B0; Thu, 21 May 2020 07:50:21 +0000 (UTC) Date: Thu, 21 May 2020 00:50:20 -0700 From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Pedro Alves Subject: Re: [PATCH v2 4/5] Provide access to non SEC_HAS_CONTENTS core file sections Message-ID: <20200521005020.697d1bf1@f31-4.lan> In-Reply-To: References: <20200513171155.645761-1-kevinb@redhat.com> <20200513171155.645761-5-kevinb@redhat.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 07:50:33 -0000 On Wed, 20 May 2020 17:45:28 +0100 Pedro Alves wrote: > So, as discussed at , > I still think that this is an heuristic, and that we're trading one > bug for another. It does seem like the bug that we're fixing > is more important than the one we're introducing, so if there's really > nothing else in the core file that would distinguish the coremaker_ro > case from an anonymous mapping that should be read from the core (i.e., > read as zeroes), then I suppose this is the best we can do, and the > patch looks good to me. I would like to see the commit log and the > comments slightly adjusted to mention this, though. On Linux, we're able to do "info proc mappings" when looking at a corefile. Linux core files include a .note.linuxcore.file/pid section which contain the map data that you see when running "info proc mappings". It may be possible to use these mappings to provide a more accurate view of memory contents when working with a core file. In addition to file backed data that we already know about from the executable and shared libraries, there may be additional file backed data that can be found via files listed in the .note section mentioned earlier. Or, as I found while investigating that one of those weird F27 mappings, there may be data from a shared library which can't be found in what GDB knows about when loading the shared library. (In that particular case, the memory region in question contained some vtable data prior to being remapped - though I'm guessing about the remapping bit.) If you think it worth pursuing, I can look at using the core-provided proc mapping information to provide a more accurate view of memory when looking at a core dump. If I do this, is it still worth pushing this v2 series first? Or should it wait until I attempt to incorporate info from the .note section? > Could you remind me again why is it that the core dump includes a > load segment for coremaker_ro in the first place? If this is > read-only data, why did the kernel decide to output a bss-like > load segment for it? On F27 and F28, coremaker_ro was placed on a page that also had read/write data; it got included in with that data when the core file was written. On F29 and beyond (due to use of particular bintutils verions/options which participated in making the executable), coremaker_ro was placed on a page with only read-only data. In this case, the core file didn't include data for that page; it lets the debugger find that data from the executable. Kevin