From: Jim Blandy <jimb@codesourcery.com>
To: Michael Eager <eager@eagercon.com>
Cc: gdb@sources.redhat.com
Subject: Re: Non-uniform address spaces
Date: Mon, 25 Jun 2007 19:05:00 -0000 [thread overview]
Message-ID: <m3zm2n6ejt.fsf@codesourcery.com> (raw)
In-Reply-To: <46800482.4020700@eagercon.com> (Michael Eager's message of "Mon, 25 Jun 2007 11:08:02 -0700")
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.
next prev parent reply other threads:[~2007-06-25 19:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-23 16:31 Michael Eager
2007-06-23 21:25 ` Daniel Jacobowitz
2007-06-23 21:47 ` Michael Eager
2007-06-23 23:09 ` Daniel Jacobowitz
2007-06-25 17:46 ` Jim Blandy
2007-06-25 18:08 ` Michael Eager
2007-06-25 19:05 ` Jim Blandy [this message]
2007-06-25 19:09 ` Daniel Jacobowitz
2007-06-25 20:04 ` Michael Eager
2007-06-25 22:23 ` Jim Blandy
2007-06-25 22:55 ` Michael Eager
2007-06-25 23:08 ` basic gdb usage question Matt Funk
[not found] ` <655C3D4066B7954481633935A40BB36F041415@ussunex02.svl.access-company.com>
2007-06-25 23:36 ` Matt Funk
2007-06-26 1:25 ` Michael Eager
2007-06-26 3:12 ` Eli Zaretskii
2007-06-26 16:13 ` Matt Funk
2007-06-27 3:29 ` Eli Zaretskii
2007-06-26 16:56 ` Non-uniform address spaces Jim Blandy
2007-06-26 17:22 ` Michael Eager
2007-06-26 17:55 ` Jim Blandy
2007-06-26 18:08 ` Jim Blandy
2007-06-26 23:08 ` Michael Eager
2007-06-26 23:39 ` Jim Blandy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3zm2n6ejt.fsf@codesourcery.com \
--to=jimb@codesourcery.com \
--cc=eager@eagercon.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox