This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Address spaces
- From: "Doug Evans" <dje at google dot com>
- To: "Stan Shebs" <stanshebs at earthlink dot net>
- Cc: gdb at sourceware dot org
- Date: Wed, 23 Jul 2008 17:14:10 -0700
- Subject: Re: Address spaces
- References: <4887C7BD.80601@earthlink.net>
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.]
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
>
>