Re: Address spaces

[Andrew Cagney <cagney@gnu.org>]

Stan Shebs 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.
>

[I point this out as it might provide you with a tangable example of a 
change that may, or may not, benefit from an implementation in C++]

I suspect that what we're describing here is something like:

frame
  has-a thread

thread
  has-a address_space

address_space
   -> what a processor / task sees (I & D?)
  has-a-multiple segment/section
      -> for instance a shared object (or program mapped into memory); 
and by implication methods for doing address <-> symbol lookups
  has-a-multiple low-level-breakpoint
      -> more on this below

address
  has-a address_space
  has-a offset -- the current CORE_ADDR

but if we examine the code, some of this is less clear.  As you 
noticed,, for a large part, the address-space is implied by the 
context.  For instance, given a specified frame, do an address/name lookup.

It might also be useful to examine a specific case which gdb, without 
something like the above, can't a program correctly; credit to pmuldoon 
for some of the ideas here.

Let's consider a vfork.  If GDB is tracing both the parent and child of 
a vfork then it will likely end up with an object relationship as follows:

         v-parent    v-child
             |         |
             `----+----'
                  |
             address_space

that is, both the vfork parent and child, after the vfork, but before 
the exec/exit, share a common address_space.  Why?  Because, this 
correctly reflects how the parent and child share memory, code, and even 
breakpoints.  For instance, since the v-child shares the v-parent's 
address space, the v-child can hit the v-parent's breakpoints, and this 
model lets us represent this.