This is the mail archive of the 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

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

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.

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