From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4999 invoked by alias); 24 Jul 2008 18:17:09 -0000 Received: (qmail 4986 invoked by uid 22791); 24 Jul 2008 18:17:08 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Jul 2008 18:16:34 +0000 Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out3.google.com with ESMTP id m6OIGQvh015642 for ; Thu, 24 Jul 2008 19:16:26 +0100 Received: from rv-out-0506.google.com (rvbk40.prod.google.com [10.140.87.40]) by spaceape12.eur.corp.google.com with ESMTP id m6OIDBr0012999 for ; Thu, 24 Jul 2008 11:16:25 -0700 Received: by rv-out-0506.google.com with SMTP id k40so2286402rvb.57 for ; Thu, 24 Jul 2008 11:16:25 -0700 (PDT) Received: by 10.141.44.13 with SMTP id w13mr374980rvj.13.1216923384856; Thu, 24 Jul 2008 11:16:24 -0700 (PDT) Received: by 10.140.201.10 with HTTP; Thu, 24 Jul 2008 11:16:24 -0700 (PDT) Message-ID: Date: Thu, 24 Jul 2008 18:28:00 -0000 From: "Doug Evans" To: "Stan Shebs" Subject: Re: Address spaces Cc: "Ulrich Weigand" , gdb@sourceware.org In-Reply-To: <4888C0CE.8000502@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200807240926.m6O9QLHh026249@d12av02.megacenter.de.ibm.com> <4888C0CE.8000502@codesourcery.com> 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/msg00256.txt.bz2 On Thu, Jul 24, 2008 at 10:50 AM, Stan Shebs wrote: > 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 > > [for reference sake] At Transmeta it was useful for debugging purposes to have an x86 view of the world and a view of the underlying "real" world. [Kinda cool to be able to run the "chip" under gdb.] One could do things like "x/x x86:0x1234" or "x/x ram:0x1234". [The syntax was :
.] We also hacked in support for x86 registers, e.g. "x/x fs:0x1234", once the basic support was there it was trivial. I'm not suggesting that we do this for x86 gdb, it's just a data point. To make this work required passing the address space to the target so CORE_ADDR had to be hacked. IWBN if one didn't have to do this in a hackish way. [Hmmm, I wonder if this would be useful when running linux on qemu or when running apps under valgrind. It'd be cool to have a view of the application and a view of the underlying simulator in the same session. Maybe another use of a multi-process GDB.]