Re: Address spaces

[Stan Shebs <stan at codesourcery dot com>]

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