Re: Address spaces

Ulrich Weigand
2008-07-24T18:28:46Z

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