From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96874 invoked by alias); 20 Mar 2015 20:14:29 -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 96862 invoked by uid 89); 20 Mar 2015 20:14:28 -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; Fri, 20 Mar 2015 20:14:27 +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 (8.14.4/8.14.4) with ESMTP id t2KKEPhg031709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 20 Mar 2015 16:14:25 -0400 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 t2KKEOsY011843 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 20 Mar 2015 16:14:25 -0400 From: Sergio Durigan Junior To: Pedro Alves Cc: 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> <550AA753.7060609@redhat.com> <87lhistwmm.fsf@redhat.com> <550C70E4.4090408@redhat.com> X-URL: http://blog.sergiodj.net Date: Fri, 20 Mar 2015 20:14:00 -0000 In-Reply-To: <550C70E4.4090408@redhat.com> (Pedro Alves's message of "Fri, 20 Mar 2015 19:11:32 +0000") Message-ID: <87r3sjwhnj.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/msg00672.txt.bz2 On Friday, March 20 2015, Pedro Alves wrote: > On 03/19/2015 11:06 PM, Sergio Durigan Junior wrote: > >> However, IMHO gcore_create_callback still has some problems. For >> example, this heuristic used to determine whether a mapping should be >> dumped or not: >> >> if (write == 0 && modified == 0 && !solib_keep_data_in_core (vaddr, size)) >> { >> /* See if this region of memory lies inside a known file on disk. >> If so, we can avoid copying its contents by clearing SEC_LOAD. */ >> struct objfile *objfile; >> struct obj_section *objsec; >> >> ALL_OBJSECTIONS (objfile, objsec) >> { >> bfd *abfd = objfile->obfd; >> asection *asec = objsec->the_bfd_section; >> bfd_vma align = (bfd_vma) 1 << bfd_get_section_alignment (abfd, >> asec); >> bfd_vma start = obj_section_addr (objsec) & -align; >> bfd_vma end = (obj_section_endaddr (objsec) + align - 1) & -align; >> >> /* Match if either the entire memory region lies inside the >> section (i.e. a mapping covering some pages of a large >> segment) or the entire section lies inside the memory region >> (i.e. a mapping covering multiple small sections). >> >> This BFD was synthesized from reading target memory, >> we don't want to omit that. */ >> if (objfile->separate_debug_objfile_backlink == NULL >> && ((vaddr >= start && vaddr + size <= end) >> || (start >= vaddr && end <= vaddr + size)) >> && !(bfd_get_file_flags (abfd) & BFD_IN_MEMORY)) >> { >> flags &= ~(SEC_LOAD | SEC_HAS_CONTENTS); >> goto keep; /* Break out of two nested for loops. */ >> } >> } >> >> keep:; >> } >> >> will not be used by any code, because everyone will be passing >> 'modified' as 1 with my following patch (the only code that could pass >> 'modified' as zero was linux_find_memory_regions_full, which I will >> patch to only pass 1 as well). > > Alright. Good that that now became clear. > > I found the initial submission for that, btw: > > https://sourceware.org/ml/gdb-patches/2003-10/msg00164.html Thanks for doing that. > I wonder whether it'd be worth to keep that somehow, for the fallback > cases when /proc//smaps or some other /proc file you're relying > on for file-backed read-only region identification is missing > (because old kernel, or even /proc not mounted). Maybe not. I will not touch this code in this series, of course, but I also think that this part should be used more often. For example, there are cases when we are not sure whether the mapping needs to be dumped or not (e.g., see gdb/gnu-nat.c), and currently we are just passing 'modified = 1', which makes GDB dump those pages. I guess this is a situation where this code could help. Anyway, something that I can look into later. -- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/