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


Michael Eager <eager@eagercon.com> writes:
> 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.

Can you show me a specific example?

(I think using a 128-bit CORE_ADDR is probably the way to go.)

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

This, I'd really like to learn more about.

How do you declare such an array?  How do you index it?  What code is
generated for an array access?  How does it relate to C's rules for
pointer arithmetic?

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

There I'm using 'object' in the sense the C standard uses it.  If you
can answer my questions above, I think I'll understand this better.


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