From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33883 invoked by alias); 24 Mar 2015 23:15:36 -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 33869 invoked by uid 89); 24 Mar 2015 23:15:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 24 Mar 2015 23:15:34 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 9F0638EFC3 for ; Tue, 24 Mar 2015 23:15:33 +0000 (UTC) Received: from localhost (unused-10-15-17-126.yyz.redhat.com [10.15.17.126]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2ONFWDT007168 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Mar 2015 19:15:33 -0400 From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches Subject: Re: [PATCH 2/2] Documentation and testcase References: <1426807358-18295-1-git-send-email-sergiodj@redhat.com> <1426807358-18295-3-git-send-email-sergiodj@redhat.com> <550C7905.9090501@redhat.com> <87mw37wfd6.fsf@redhat.com> <550C9A7C.90705@redhat.com> <87wq283gmx.fsf@redhat.com> <5510773D.4010107@redhat.com> <87wq274e1w.fsf@redhat.com> <55109C7E.2040504@redhat.com> <87619q2961.fsf@redhat.com> <55113880.4060707@redhat.com> X-URL: http://blog.sergiodj.net Date: Tue, 24 Mar 2015 23:15:00 -0000 In-Reply-To: <55113880.4060707@redhat.com> (Pedro Alves's message of "Tue, 24 Mar 2015 10:12:16 +0000") Message-ID: <87egoe2dij.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00814.txt.bz2 On Tuesday, March 24 2015, Pedro Alves wrote: >> Therefore, if *also* considers tha case when the mapping is file-backed >> private (which my patch doesn't do). >> >> All this boils down to: my patch is incorrectly dumping the .text >> segment when I ask it not to do that (i.e., when I ask it to ignore >> file-backed private mappings and to dump anonymous private mappings), >> and it is *not* dumping the .text segment when I ask it to dump it >> (i.e., when I ask it to dump file-backed private mappings and to ignore >> anonymous private mappings). >> >> So, here's what I propose: I will rework this part of the patch and try >> to come up with a better way of identifying these situations (mainly: >> when a file-backed mapping has anonymous contents), and I will resubmit >> it tomorrow. Along with that, I should be able to extend the testcase >> to cover the disassemble case (and it should start to work fine once I >> make those adjustments). > > Sounds good. And I am back, with new investigations and results. This whole thing is starting to driving me crazy. What I found is interesting. When a memory mapping is file-backed, but contains Anonymous: pages, the Linux kernel dumps this region when: - The user asks for anonymous pages, *OR* - The user asks for file-backed pages Yes, it dumps the mapping in *both* scenarios. It is like a "file-backed anonymous" mapping... I adjusted my patch to mimic this behavior. However, there is one more thing... For some reason, when I run the binary inside GDB, the .text segment *contains* Anonymous: pages. However, when I run the binary outside GDB, the Anonymous: counter is always zero. This means that, inside GDB, when we ask for a corefile that excludes file-backed private mappings (i.e., the .text segment), according to the Linux kernel's rules, the .text segment *still* should be dumped because it contains Anonymous: pages. Unfortunately, I was not able to generate a binary whose .text segment contained Anonymous: pages outside GDB. However, I made a binary that has Anonymous: pages on a file-backed mapping, and I made the Linux kernel generate a corefile for it while asking it to exclude file-backed mappings, and I could confirm that the Linux kernel indeed includes this mapping in the corefile. My final proposal, which will be reflected in a patch that will be submitted soon, is to relax the test of the the disassembly of main. This way, we can still mimic what the Linux kernel does and make GDB compatible with it. Thanks, -- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/