Re: Address spaces

[Stan Shebs <stan@codesourcery.com>]

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