Re: Non-uniform address spaces

[Jim Blandy <jimb@codesourcery.com>]

Michael Eager <eager@eagercon.com> writes:
> Daniel Jacobowitz wrote:
>> On Sat, Jun 23, 2007 at 09:31:31AM -0700, Michael Eager wrote:
>>> Any suggestions on how to support a target which has
>>> a non-uniform address space?  An address is a tuple which
>>> includes a processor id, a thread id, and an offset.
>>> There is a mapping function which translates the tuple
>>> into a physical address.
>>>
>>> Ideally, it would be nice to replace the current definition
>>> of CORE_ADDR with a struct and add functions to to do
>>> operations like increment/decrement address.  But the
>>> assumption that the address space is flat and that you
>>> can do arithmetic on addresses is pervasive.
>>
>> How big are each of those objects (processor id, thread id, offset)?
>
> They would all fit in a 128-bit word.
>
>> The conventional way to do this in GDB is to have a mapping from
>> CORE_ADDR to target addresses, not to target pointers.  Most of the
>> Harvard architecture ports work this way.  However, there may not be
>> enough hooks for you to get away with it if they're as dynamic as it
>> sounds.
>
> Having a 128-bit CORE_ADDR sounds possible, but there are many
> places where there's arithmetic or comparisons done on the values.
> These would all be problematic.  Usually correct, occasionally not.

I dunno, actually --- if you look at them, I think almost all will be
okay.

GDB makes a distinction between CORE_ADDRs (which need to be able to
address all memory on the system) and actual pointers as represented
on the target.  The ADDRESS_TO_POINTER and POINTER_TO_ADDRESS gdbarch
methods convert between the two.  I think there is some discussion in
doc/gdbint.texinfo on those.

Any arithmetic the user requests (with 'print', etc.) is carried out
using target-format pointer values.  In that format, wraparound gets
implemented properly.  If it isn't, then changes to value_add and so
on would be appropriate.

I think you'll find that the operations on CORE_ADDR itself will all
be harmless.  GDB shouldn't be walking off the end of an object
anyway, so if objects don't overlap address space boundaries, then GDB
won't either.