Address spaces

Address spaces

[Stan Shebs]

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

Re: Address spaces

[Doug Evans]

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

Re: Address spaces

[Stan Shebs]

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

Re: Address spaces

[Ulrich Weigand]

Stan Shebs wrote:
> 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.)

Cell/B.E. applications have multiple address spaces per process -- the
main PowerPC address space (that is also accessible from the SPEs via
DMA operations) plus a separate local store address space for each SPE
context that is active in the process.

I'm currently using bit hacks to map all these address spaces into a
single CORE_ADDR space -- this is working OK for now, but it would
seem nicer to integrate this into a general notion of address spaces ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: Address spaces

[Stan Shebs]

Ulrich Weigand wrote:
> Stan Shebs wrote:
>   
>> 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.)
>>     
>
> Cell/B.E. applications have multiple address spaces per process -- the
> main PowerPC address space (that is also accessible from the SPEs via
> DMA operations) plus a separate local store address space for each SPE
> context that is active in the process.
>
> I'm currently using bit hacks to map all these address spaces into a
> single CORE_ADDR space -- this is working OK for now, but it would
> seem nicer to integrate this into a general notion of address spaces ...
>   
Is this code in the GDB sources now? I'm not seeing anything obvious. 
But I'm guessing you mean that there can be a main() for the PPE and a 
main() for each SPE, and that they can all be literally at 0x12480, but 
since GDB wouldn't like that you have to do trickery in the target 
before anything is delivered to GDB?

The possibility of overlapping address spaces makes my head hurt a 
little. :-)

Stan

Re: Address spaces

[Doug Evans]

On Thu, Jul 24, 2008 at 10:50 AM, Stan Shebs <stan@codesourcery.com> wrote:
> Ulrich Weigand wrote:
>>
>> Stan Shebs wrote:
>>
>>>
>>> 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.)
>>>
>>
>> Cell/B.E. applications have multiple address spaces per process -- the
>> main PowerPC address space (that is also accessible from the SPEs via
>> DMA operations) plus a separate local store address space for each SPE
>> context that is active in the process.
>>
>> I'm currently using bit hacks to map all these address spaces into a
>> single CORE_ADDR space -- this is working OK for now, but it would
>> seem nicer to integrate this into a general notion of address spaces ...
>>
>
> Is this code in the GDB sources now? I'm not seeing anything obvious. But
> I'm guessing you mean that there can be a main() for the PPE and a main()
> for each SPE, and that they can all be literally at 0x12480, but since GDB
> wouldn't like that you have to do trickery in the target before anything is
> delivered to GDB?
>
> The possibility of overlapping address spaces makes my head hurt a little.
> :-)
>
> Stan
>
>

[for reference sake]
At Transmeta it was useful for debugging purposes to have an x86 view
of the world and a view of the underlying "real" world.  [Kinda cool
to be able to run the "chip" under gdb.]   One could do things like
"x/x x86:0x1234" or "x/x ram:0x1234".  [The syntax was
<address-space>:<address>.]  We also hacked in support for x86
registers, e.g. "x/x fs:0x1234", once the basic support was there it
was trivial.  I'm not suggesting that we do this for x86 gdb, it's
just a data point.  To make this work required passing the address
space to the target so CORE_ADDR had to be hacked.  IWBN if one didn't
have to do this in a hackish way.

[Hmmm, I wonder if this would be useful when running linux on qemu or
when running apps under valgrind.  It'd be cool to have a view of the
application and a view of the underlying simulator in the same
session.  Maybe another use of a multi-process GDB.]

Re: Address spaces

[Ulrich Weigand]

Stan Shebs wrote:

> Is this code in the GDB sources now? I'm not seeing anything obvious. 

Not yet; I'm still working on cleaning it up ...

> But I'm guessing you mean that there can be a main() for the PPE and a 
> main() for each SPE, and that they can all be literally at 0x12480, but 
> since GDB wouldn't like that you have to do trickery in the target 
> before anything is delivered to GDB?

Yes, exactly.   For address encoding into CORE_ADDR I'm using this:

#define SPUADDR(spu, addr) \
        ((spu) && !spu_standalone_p ()? \
         (((ULONGEST)1 << 63) | ((ULONGEST)(spu)) << 32 | (addr)) : (addr))
#define SPUADDR_SPU(addr) \
        (((addr) & ((ULONGEST)1 << 63))? (((ULONGEST)(addr) >> 32) & 0x7fffffff) : 0)
#define SPUADDR_ADDR(addr) \
        (((addr) & ((ULONGEST)1 << 63))? ((ULONGEST)(addr) & 0xffffffff) : (addr))

I.e. CORE_ADDR values with MSB 0 encode regular PowerPC addresses, while
CORE_ADDR values with MSB 1 encode a tuple of SPU context ID + local store
address (this works as SPU IDs are basically file descriptors and local
store addresses are limited to 18 bits) ...

I'm using a special "shared library" target to re-map the SPU executables
at the mangled addresses as far as GDB core is concerned.  A special target
stack implements a xfer_partial that unmangles addresses and accesses either
PowerPC memory or some SPU local store, as appropriate ...

If you're interested into more details, I'll be happy to send you my 
current patchset.

What does *not* work satisfactorily in all circumstances right now are user
interface issues.  I don't want to expose the mangled CORE_ADDR to the user,
so the extra bits are stripped via gdbarch_addr_bits, and reinserted by the
gdbarch_integer_to_pointer family of functions, based on whether the currently
selected frame is SPU or PowerPC code.

This makes it e.g. impossible to input a PowerPC address while in a SPU frame,
which would be useful occasionally.  To do that right we'd have to expose a
user interface mechanism to select address spaces, though.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: Address spaces

[Paul Pluzhnikov]

On Wed, Jul 23, 2008 at 5:29 PM, Stan Shebs <stan@codesourcery.com> wrote:

> Doug Evans wrote:

>> It would be useful to have proper address spaces for non-multi-process
>> situations 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.

Here is another use case:

I just spoke with someone who debugs a process on x86 which
dynamically switches between "flat" 32-bit address space, and
(possibly several) "restricted" 28-bit address sub-spaces (which
are using CS, DS, and segment limits) in the same process.

Think privileged and untrusted code mixed into the same process,
with well-defined rules of transition between them.

-- 
Paul Pluzhnikov

Re: Address spaces

[Michael Snyder]

On Wed, 2008-07-23 at 17:29 -0700, Stan Shebs wrote:
> 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.

Harvard architectures?

Segmented architectures (intel real mode)?  CS:deadbeef
vs. DS:deadbeef?


>  (Instantly split I/D targets a 
> la D10V come to mind, although that was handled by distinguishing 
> pointers from addresses.)

I have a half-recollection of doing a target that had a
"code:" addr space and a "data:" addr space.  Can't remember
if that ever got contributed?

Anyway, the idea of making CORE_ADDR a struct has been 
around for a long time.  We've done our best to avoid it, 
but sort of always known it would come back one day.

Re: Address spaces

[Michael Snyder]

On Thu, 2008-07-24 at 11:26 +0200, Ulrich Weigand wrote:
> Stan Shebs wrote:
> > 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.)
> 
> Cell/B.E. applications have multiple address spaces per process -- the
> main PowerPC address space (that is also accessible from the SPEs via
> DMA operations) plus a separate local store address space for each SPE
> context that is active in the process.
> 
> I'm currently using bit hacks to map all these address spaces into a
> single CORE_ADDR space -- this is working OK for now, but it would
> seem nicer to integrate this into a general notion of address spaces ...

Oh yeah, and how about multi-core arches, like with a DSP copro or
something?

Re: Address spaces

[Michael Snyder]

> [Hmmm, I wonder if this would be useful when running linux on qemu or
> when running apps under valgrind.  It'd be cool to have a view of the
> application and a view of the underlying simulator in the same
> session.  Maybe another use of a multi-process GDB.]

Virtual monitor view plus guest os view?

Re: Address spaces

[Jeremy Bennett]

>>> Doug Evans wrote:
>>>
>>> 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.)

This would be useful for architectures which have large numbers of
configuration registers. These are not always mapped in the main address
space. They could conveniently be represented in a separate address
space. Examples include the OpenCores OpenRISC 1000 special purpose
registers and the ARC 600/700 auxiliary address space.


Jeremy Bennett
-- 
Tel:      +44 (1202) 416955
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   jeremy.bennett@embecosm.com
Web:     www.embecosm.com

Re: Address spaces

[Stan Shebs]

Michael Snyder wrote:
> Anyway, the idea of making CORE_ADDR a struct has been 
> around for a long time.  We've done our best to avoid it, 
> but sort of always known it would come back one day.
>   
Where my prototyping is evolving is to have a new type of object that is 
the struct, tentatively called "target address", consisting of address 
space + CORE_ADDR. From poking through all the references to CORE_ADDR, 
it looks to me like 90%+ have an implicit single address space, so 
structifying seems like an unnecessary nuisance. For instance, when 
you're doing prologue analysis you're only going to be working in the 
one address space (at least for non-Harvard). So I'm thinking higher 
levels will pass around target addresses in a mostly-opaque way, then 
when one gets down to working on a specific program / address space, the 
CORE_ADDRs are extracted and used much as they are now.

While not as abstractly elegant as making all addresses into objects 
right off, it doesn't preclude us from going in that direction; someone 
who wants to make a subsystem use target addresses instead of CORE_ADDRs 
throughout could do so.

Stan

Re: Address spaces

[Stan Shebs]

Ulrich Weigand wrote:
> If you're interested into more details, I'll be happy to send you my 
> current patchset.
>   
Thanks, I don't think I need them.
> What does *not* work satisfactorily in all circumstances right now are user
> interface issues.  I don't want to expose the mangled CORE_ADDR to the user,
> so the extra bits are stripped via gdbarch_addr_bits, and reinserted by the
> gdbarch_integer_to_pointer family of functions, based on whether the currently
> selected frame is SPU or PowerPC code.
>
> This makes it e.g. impossible to input a PowerPC address while in a SPU frame,
> which would be useful occasionally.  To do that right we'd have to expose a
> user interface mechanism to select address spaces, though.
>   
Between yours and Doug's and Paul's and Michael's examples :-) , I think 
it's pretty clear that we will want some kind of user interface. In the 
general case, a target can create arbitrarily-named address spaces, 
while in the conventional multiprogram case, address space names could 
simply be copied from exec names or process ids.

Stan

Re: Address spaces

[Mark Kettenis]

> Date: Fri, 25 Jul 2008 11:22:11 -0700
> From: Stan Shebs <stanshebs@earthlink.net>
> 
> Michael Snyder wrote:
> > Anyway, the idea of making CORE_ADDR a struct has been 
> > around for a long time.  We've done our best to avoid it, 
> > but sort of always known it would come back one day.
> >   
> Where my prototyping is evolving is to have a new type of object that is 
> the struct, tentatively called "target address", consisting of address 
> space + CORE_ADDR. From poking through all the references to CORE_ADDR, 
> it looks to me like 90%+ have an implicit single address space, so 
> structifying seems like an unnecessary nuisance. For instance, when 
> you're doing prologue analysis you're only going to be working in the 
> one address space (at least for non-Harvard). So I'm thinking higher 
> levels will pass around target addresses in a mostly-opaque way, then 
> when one gets down to working on a specific program / address space, the 
> CORE_ADDRs are extracted and used much as they are now.
> 
> While not as abstractly elegant as making all addresses into objects 
> right off, it doesn't preclude us from going in that direction; someone 
> who wants to make a subsystem use target addresses instead of CORE_ADDRs 
> throughout could do so.

Did you consider extending 'struct ptid' with an adress space
identifier?  In a way, POSIX processes already correspond to an
address space, and the ptid is likely to be available in many places
where you need to make the distinction.

Re: Address spaces

[Stan Shebs]

Mark Kettenis wrote:
>> Date: Fri, 25 Jul 2008 11:22:11 -0700
>> From: Stan Shebs <stanshebs@earthlink.net>
>>
>> Michael Snyder wrote:
>>     
>>> Anyway, the idea of making CORE_ADDR a struct has been 
>>> around for a long time.  We've done our best to avoid it, 
>>> but sort of always known it would come back one day.
>>>   
>>>       
>> Where my prototyping is evolving is to have a new type of object that is 
>> the struct, tentatively called "target address", consisting of address 
>> space + CORE_ADDR. From poking through all the references to CORE_ADDR, 
>> it looks to me like 90%+ have an implicit single address space, so 
>> structifying seems like an unnecessary nuisance. For instance, when 
>> you're doing prologue analysis you're only going to be working in the 
>> one address space (at least for non-Harvard). So I'm thinking higher 
>> levels will pass around target addresses in a mostly-opaque way, then 
>> when one gets down to working on a specific program / address space, the 
>> CORE_ADDRs are extracted and used much as they are now.
>>
>> While not as abstractly elegant as making all addresses into objects 
>> right off, it doesn't preclude us from going in that direction; someone 
>> who wants to make a subsystem use target addresses instead of CORE_ADDRs 
>> throughout could do so.
>>     
>
> Did you consider extending 'struct ptid' with an adress space
> identifier?  In a way, POSIX processes already correspond to an
> address space, and the ptid is likely to be available in many places
> where you need to make the distinction.
>   
Struct ptid is handy, but by nature it's tied to running inferiors, 
seems like it would be a little out of place if we needed it to to look 
at execs and symbol files before running.

Stan

Re: Address spaces

[Andrew Cagney]

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.