Re: Address spaces

Andrew Cagney
2008-07-31T15:37:08Z

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.