Re: Non-uniform address spaces

[Michael Eager <eager@eagercon.com>]

Jim Blandy wrote:
> 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.

No, there are non-uniform address architectures where you can't simply
increment or decrement a pointer without recalculating the values
of the components of the address.

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

This is the problem:  the pervasive assumption in GDB is that a CORE_ADDR
is a simple, linear value.   In a NUMA architecture, this is not true.
Actual pointers on the hardware may be simple addresses, but they may be
in arbitrary address spaces.  The translation to a target address is OK,
but the operations on CORE_ADDR are incorrect.

Operations as simple as array indexing may require a computation that
is more complex than a simple multiplication.  An array may be split
between multiple address spaces.  The computation may not be complex,
but it is not as simple as a multiply and addition.

On a NUMA system, a CORE_ADDR may well meet the requirement that it
can address all memory.  It doesn't meet the assumption that it is
linear and contiguous.

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

The assumption that objects don't cross address space boundaries
is not valid.  Multiprocessor systems split data across multiple
processors, each of which has a separate data space.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077