This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Address spaces
- From: Andrew Cagney <cagney at gnu dot org>
- To: Stan Shebs <stanshebs at earthlink dot net>
- Cc: gdb at sourceware dot org
- Date: Thu, 31 Jul 2008 11:36:44 -0400
- Subject: Re: Address spaces
- References: <4887C7BD.80601@earthlink.net>
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.