From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17481 invoked by alias); 19 Mar 2015 10:39: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 17418 invoked by uid 89); 19 Mar 2015 10:39: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; Thu, 19 Mar 2015 10:39: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 t2JAdHuu023205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 19 Mar 2015 06:39:17 -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 t2JAdGgZ023781; Thu, 19 Mar 2015 06:39:16 -0400 Message-ID: <550AA753.7060609@redhat.com> Date: Thu, 19 Mar 2015 10:39: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 , GDB Patches Subject: Re: [PATCH 1/4] Improve identification of memory mappings References: <1426707523-6499-1-git-send-email-sergiodj@redhat.com> <1426707523-6499-2-git-send-email-sergiodj@redhat.com> In-Reply-To: <1426707523-6499-2-git-send-email-sergiodj@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00577.txt.bz2 Thanks for splitting. It indeed makes it easier to understand the changes. On 03/18/2015 07:38 PM, Sergio Durigan Junior wrote: > This commit implements the new 'enum memory_mapping_state', which can > be used to represent the different states of each memory mapping from > the inferior. These states are: > > - MODIFIED, which means that the mapping should be dumped in > corefiles > > - UNMODIFIED, which means that the mapping should not be dumped in > corefiles (e.g., mappings that have been marked as VM_DONTDUMP), and > > - UNKNOWN, which means that we don't know whether the mapping should > or should not be dumped. > I'm sorry to push back on this, but it sounds to me that this is mixing up orthogonal aspects. For example, what if a mapping is indeed modified, but the tdep code decides it should not be dumped? With this interface, you need to "lie" and pass down UNMODIFIED. And then, what if a mapping is definitely not modified, but the tdep code decides it should dumped (e.g., say we could tell that the vdso mapping really wasn't modified, but we still want to dump it anyhow because there's no file on the filesystem to read the vdso contents from later at core load time). With this interface, you need to pass down either MODIFIED or UNKNOWN. So it sounds to me that instead, the arch/target code that is walking the memory mappings should just not call the "dump this mapping" callback if it decides the mapping should not be dumped. And if we do _that_ first, then, what other changes to gcore_create_callback would be required to make it do what we need? This may need further discussion, but in any case, note that the descriptions above of what each state means ... > +/* Enum used to inform the state of a memory mapping. This is used in > + functions implementing find_memory_region_ftype. */ > + > +enum memory_mapping_state > + { > + MEMORY_MAPPING_MODIFIED, > + MEMORY_MAPPING_UNMODIFIED, > + MEMORY_MAPPING_UNKNOWN_STATE, > + }; ... should be here in the code. Thanks, Pedro Alves