Re: Address spaces

["Doug Evans" <dje@google.com>]

On Thu, Jul 24, 2008 at 10:50 AM, Stan Shebs <stan@codesourcery.com> 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
<address-space>:<address>.]  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.]