From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8417 invoked by alias); 24 Jul 2008 17:50:38 -0000 Received: (qmail 8408 invoked by uid 22791); 24 Jul 2008 17:50:37 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Jul 2008 17:50:18 +0000 Received: (qmail 30879 invoked from network); 24 Jul 2008 17:50:17 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Jul 2008 17:50:17 -0000 Message-ID: <4888C0CE.8000502@codesourcery.com> Date: Thu, 24 Jul 2008 18:17:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Ulrich Weigand CC: Stan Shebs , Doug Evans , gdb@sourceware.org Subject: Re: Address spaces References: <200807240926.m6O9QLHh026249@d12av02.megacenter.de.ibm.com> In-Reply-To: <200807240926.m6O9QLHh026249@d12av02.megacenter.de.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/msg00255.txt.bz2 Ulrich Weigand wrote: > 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 ... > Is this code in the GDB sources now? I'm not seeing anything obvious. But I'm guessing you mean that there can be a main() for the PPE and a main() for each SPE, and that they can all be literally at 0x12480, but since GDB wouldn't like that you have to do trickery in the target before anything is delivered to GDB? The possibility of overlapping address spaces makes my head hurt a little. :-) Stan