This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Non-uniform address spaces


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]