From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15469 invoked by alias); 24 Mar 2015 10:12:21 -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 15439 invoked by uid 89); 24 Mar 2015 10:12:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 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 10:12:19 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2OACIoS022088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 24 Mar 2015 06:12:18 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2OACGKG019011; Tue, 24 Mar 2015 06:12:17 -0400 Message-ID: <55113880.4060707@redhat.com> Date: Tue, 24 Mar 2015 10:12:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sergio Durigan Junior 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> In-Reply-To: <87619q2961.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00785.txt.bz2 On 03/24/2015 06:37 AM, Sergio Durigan Junior wrote: > > The Linux kernel uses the bit 4 on the coredump_filter file to determine > whether it should dump ELF headers or not. According to vma_dump_size: ... > So maybe this is what you meant above by "that one ends up always > dumped...", when refering to the first page of the text segment? Well, > that is partially true: if you unset bit 4, you will see that this page > does not get dumped at all (and therefore we see the "Cannot access > memory..." error; I did some experiments here and confirmed that). Ah, indeed I probably had bit 4 set. > 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. > > Phew! What a confusion... :-/. I hope things are clearer with this > e-mail. Thanks, Pedro Alves