From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26841 invoked by alias); 9 Nov 2011 16:37:48 -0000 Received: (qmail 26831 invoked by uid 22791); 9 Nov 2011 16:37:47 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Nov 2011 16:37:28 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1ROB9S-0006HB-WB from pedro_alves@mentor.com ; Wed, 09 Nov 2011 08:37:27 -0800 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Nov 2011 16:37:24 +0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [rfc][3/3] Remote core file generation: memory map Date: Wed, 09 Nov 2011 16:37:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-12-generic; KDE/4.7.2; x86_64; ; ) Cc: "Ulrich Weigand" , jan.kratochvil@redhat.com References: <201111081725.pA8HPaFc003696@d06av02.portsmouth.uk.ibm.com> In-Reply-To: <201111081725.pA8HPaFc003696@d06av02.portsmouth.uk.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111091637.23350.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2011-11/txt/msg00233.txt.bz2 On Tuesday 08 November 2011 17:25:36, Ulrich Weigand wrote: > I wrote: > > Jan Kratochvil wrote: > > > On Fri, 21 Oct 2011 20:57:04 +0200, Ulrich Weigand wrote: > > > > Note that there already is a qXfer:memory-map:read packet, but this > > > > is not usable as-is to implement target_find_memory_regions, since > > > > it is really intended for a *system* memory map for some naked > > > > embedded targets instead of a per-process virtual address space map. > > > > > > > > For example: > > > > > > > > - the memory map is read into a single global mem_region list; it is not > > > > switched for multiple inferiors > > > > > > Without extended-remote there is a single address map only. Is the memory map > > > already useful with extended-remote using separate address spaces? > > > > > > I do not have the embedded memory map experience but it seems to me the memory > > > map should be specified for each address map, therefore for each inferior it > > > is OK (maybe only possibly more duplicates are sent if the address spaces are > > > the same). If GDB uses the memory map it uses it already for some inferior > > > and therefore its address space. > > > > The problem is that the way GDB uses the memory map is completely > > incompatible with the presence of multiple address spaces. > > > > There is a single instance of the map (kept in a global variable > > mem_region_list in memattr.c), which is used for any access in > > any address space. lookup_mem_region takes only a CORE_ADDR; > > the "info mem" commands only operate on addresses with no notion > > of address spaces. That's mostly because we never really needed to consider making it per multi-process/inferior/exec before, and managed to just look the other way. Targets that do multi-process don't use the map presently. I'm sure there are other things that live in globals but that should be per-inferior or address space, waiting for someone to trip on them, and eventually get fixed. :-) > Another problem just occurred to me: the memory region list is > cached during the whole duration of existence of the inferior. > This caching is really necessary, since the map is consulted > during each single memory access. And it seems quite valid to > cache the map as long as it describes fixed features of the > architecture (i.e. RAM/ROM/Flash layout). > > However, once the map describes VMA mappings in a process context, > it becomes highly dynamic as memory maps come and go ... It is > no longer really feasible to cache the map contents then. Agreed. > This seems to me to be an argument *for* splitting the contents into > two maps; the system map which is static and cached (and used for > each memory access), and the per-process map which is dynamic > and uncached (and only used rarely, in response to unfrequently > used user commands) ... On e.g., uclinux / no mmu, you could have both the system memory map returning the properties of memory of the whole system, and gdb could use that for all memory accesses, but, when generating a core of a single process, we're only interested in the memory "mapped" to that process. So I tend to agree. We could also make the existing memory map be per-process/aspace, and define it describe only the process's map (a process is a means of a virtualization of the system resources after all). The dynamic issue with process's memory maps then becomes a cache management policy decision. E.g., at times we know the map can't change (all is stopped, or by user knob), this would automatically enable the dcache for all RO regions (mostly .text). We can still do this while having two maps mechanism though. It doesn't seem there's a true answer to this, but I'm leaning on a new target object. -- Pedro Alves