From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14105 invoked by alias); 24 Jul 2008 18:28:46 -0000 Received: (qmail 14092 invoked by uid 22791); 24 Jul 2008 18:28:46 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Jul 2008 18:28:24 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id m6OIRcrw046446 for ; Thu, 24 Jul 2008 18:27:38 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 m6OIRcU84317282 for ; Thu, 24 Jul 2008 20:27:38 +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 m6OIRcdg010811 for ; Thu, 24 Jul 2008 20:27:38 +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 m6OIRcJo010808; Thu, 24 Jul 2008 20:27:38 +0200 Message-Id: <200807241827.m6OIRcJo010808@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 24 Jul 2008 20:27:38 +0200 Subject: Re: Address spaces To: stan@codesourcery.com (Stan Shebs) Date: Thu, 24 Jul 2008 20:31:00 -0000 From: "Ulrich Weigand" Cc: dje@google.com (Doug Evans), gdb@sourceware.org In-Reply-To: <4888C0CE.8000502@codesourcery.com> from "Stan Shebs" at Jul 24, 2008 10:50:06 AM 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/msg00257.txt.bz2 Stan Shebs wrote: > Is this code in the GDB sources now? I'm not seeing anything obvious. Not yet; I'm still working on cleaning it up ... > 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? Yes, exactly. For address encoding into CORE_ADDR I'm using this: #define SPUADDR(spu, addr) \ ((spu) && !spu_standalone_p ()? \ (((ULONGEST)1 << 63) | ((ULONGEST)(spu)) << 32 | (addr)) : (addr)) #define SPUADDR_SPU(addr) \ (((addr) & ((ULONGEST)1 << 63))? (((ULONGEST)(addr) >> 32) & 0x7fffffff) : 0) #define SPUADDR_ADDR(addr) \ (((addr) & ((ULONGEST)1 << 63))? ((ULONGEST)(addr) & 0xffffffff) : (addr)) I.e. CORE_ADDR values with MSB 0 encode regular PowerPC addresses, while CORE_ADDR values with MSB 1 encode a tuple of SPU context ID + local store address (this works as SPU IDs are basically file descriptors and local store addresses are limited to 18 bits) ... I'm using a special "shared library" target to re-map the SPU executables at the mangled addresses as far as GDB core is concerned. A special target stack implements a xfer_partial that unmangles addresses and accesses either PowerPC memory or some SPU local store, as appropriate ... If you're interested into more details, I'll be happy to send you my current patchset. What does *not* work satisfactorily in all circumstances right now are user interface issues. I don't want to expose the mangled CORE_ADDR to the user, so the extra bits are stripped via gdbarch_addr_bits, and reinserted by the gdbarch_integer_to_pointer family of functions, based on whether the currently selected frame is SPU or PowerPC code. This makes it e.g. impossible to input a PowerPC address while in a SPU frame, which would be useful occasionally. To do that right we'd have to expose a user interface mechanism to select address spaces, though. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com