Address spaces

[Stan Shebs]

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.)

Stan
> On Wed, Jul 23, 2008 at 5:07 PM, Stan Shebs <stanshebs@earthlink.net> wrote:
>   
>> One of the recurring themes I'm noticing in my little bit of prototyping for
>> multiprogram GDB is the need for a general concept of "address space". It's
>> not quite the same as program/exec, because several programs could be in one
>> address space in a non-virtual-memory system. It's not quite the same as
>> process, because it applies to address lookup in execs prior to running any
>> of them. It seems most like a tag glued on the front of a CORE_ADDR in fact
>> (change CORE_ADDR to a struct? urgh).
>>
>> Anyway, I'm just throwing this out to get people's thoughts, and see if I'm
>> missing an existing basic type or bit of infrastructure that could serve the
>> purpose. I don't think address space objects would be user-visible, nor have
>> very many properties; I think their main purpose in practice will be to keep
>> target addresses in different execs and processes from getting mixed up with
>> each other.
>>
>> Stan
>>
>>
>>     
>
>