From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19056 invoked by alias); 31 Jul 2008 15:37:08 -0000 Received: (qmail 19046 invoked by uid 22791); 31 Jul 2008 15:37:06 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 Jul 2008 15:36:49 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6VFalua009825; Thu, 31 Jul 2008 11:36:47 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6VFakTB020819; Thu, 31 Jul 2008 11:36:46 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6VFajEE018310; Thu, 31 Jul 2008 11:36:46 -0400 Message-ID: <4891DC0C.8060503@gnu.org> Date: Thu, 31 Jul 2008 18:43:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Stan Shebs CC: gdb@sourceware.org Subject: Re: Address spaces References: <4887C7BD.80601@earthlink.net> In-Reply-To: <4887C7BD.80601@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00351.txt.bz2 Stan Shebs wrote: > One of the recurring themes I'm noticing in my little bit of > prototyping for multiprogram GDB is the need for a general concept of > "address space". It's not quite the same as program/exec, because > several programs could be in one address space in a non-virtual-memory > system. It's not quite the same as process, because it applies to > address lookup in execs prior to running any of them. It seems most > like a tag glued on the front of a CORE_ADDR in fact (change CORE_ADDR > to a struct? urgh). > > Anyway, I'm just throwing this out to get people's thoughts, and see > if I'm missing an existing basic type or bit of infrastructure that > could serve the purpose. I don't think address space objects would be > user-visible, nor have very many properties; I think their main > purpose in practice will be to keep target addresses in different > execs and processes from getting mixed up with each other. > [I point this out as it might provide you with a tangable example of a change that may, or may not, benefit from an implementation in C++] I suspect that what we're describing here is something like: frame has-a thread thread has-a address_space address_space -> what a processor / task sees (I & D?) has-a-multiple segment/section -> for instance a shared object (or program mapped into memory); and by implication methods for doing address <-> symbol lookups has-a-multiple low-level-breakpoint -> more on this below address has-a address_space has-a offset -- the current CORE_ADDR but if we examine the code, some of this is less clear. As you noticed,, for a large part, the address-space is implied by the context. For instance, given a specified frame, do an address/name lookup. It might also be useful to examine a specific case which gdb, without something like the above, can't a program correctly; credit to pmuldoon for some of the ideas here. Let's consider a vfork. If GDB is tracing both the parent and child of a vfork then it will likely end up with an object relationship as follows: v-parent v-child | | `----+----' | address_space that is, both the vfork parent and child, after the vfork, but before the exec/exit, share a common address_space. Why? Because, this correctly reflects how the parent and child share memory, code, and even breakpoints. For instance, since the v-child shares the v-parent's address space, the v-child can hit the v-parent's breakpoints, and this model lets us represent this.