This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Non-uniform address spaces
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.