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


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 thought most of the HA systems just increased the address size by
one bit and had the high-order bit specify whether the address
was in D or I address 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]