From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31191 invoked by alias); 24 Jul 2008 09:26:48 -0000 Received: (qmail 31180 invoked by uid 22791); 24 Jul 2008 09:26:47 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate7.de.ibm.com (HELO mtagate7.de.ibm.com) (195.212.29.156) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Jul 2008 09:26:26 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id m6O9QM6k364978 for ; Thu, 24 Jul 2008 09:26:22 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6O9QMOg2093256 for ; Thu, 24 Jul 2008 11:26:22 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6O9QL4f026252 for ; Thu, 24 Jul 2008 11:26:22 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m6O9QLHh026249; Thu, 24 Jul 2008 11:26:21 +0200 Message-Id: <200807240926.m6O9QLHh026249@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 24 Jul 2008 11:26:21 +0200 Subject: Re: Address spaces To: stan@codesourcery.com (Stan Shebs) Date: Thu, 24 Jul 2008 15:56:00 -0000 From: "Ulrich Weigand" Cc: dje@google.com (Doug Evans), gdb@sourceware.org In-Reply-To: <4887CCF2.6020503@codesourcery.com> from "Stan Shebs" at Jul 23, 2008 05:29:38 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00253.txt.bz2 Stan Shebs wrote: > Doug Evans wrote: > > It would be useful to have proper address spaces for non-multi-process > > situations too. At the moment all one can do is hack in bits to > > unused parts of the address (assuming such bits are available ...). > > [I'm sure this isn't news. Just saying there are multiple reasons for > > addresses being more than just the CORE_ADDR of today, and if we solve > > one, let's at least consider the others too.] > > > Do you have some specific ideas in mind? Because I was assuming (and > this is good to be aware of) that there would not be more than one > address space associated with a process. (Instantly split I/D targets a > la D10V come to mind, although that was handled by distinguishing > pointers from addresses.) Cell/B.E. applications have multiple address spaces per process -- the main PowerPC address space (that is also accessible from the SPEs via DMA operations) plus a separate local store address space for each SPE context that is active in the process. I'm currently using bit hacks to map all these address spaces into a single CORE_ADDR space -- this is working OK for now, but it would seem nicer to integrate this into a general notion of address spaces ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com