From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8951 invoked by alias); 25 Jun 2007 18:08:09 -0000 Received: (qmail 8943 invoked by uid 22791); 25 Jun 2007 18:08:08 -0000 X-Spam-Check-By: sourceware.org Received: from shell4.bayarea.net (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 25 Jun 2007 18:08:05 +0000 Received: (qmail 16353 invoked from network); 25 Jun 2007 11:08:03 -0700 Received: from 209-128-106-254.bayarea.net (HELO ?192.168.20.7?) (209.128.106.254) by shell4.bayarea.net with SMTP; 25 Jun 2007 11:08:03 -0700 Message-ID: <46800482.4020700@eagercon.com> Date: Mon, 25 Jun 2007 18:08:00 -0000 From: Michael Eager User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Jim Blandy CC: gdb@sources.redhat.com Subject: Re: Non-uniform address spaces References: <467D4AE3.7020505@eagercon.com> <20070623212557.GB3448@caradoc.them.org> <467D9503.9060804@eagercon.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00245.txt.bz2 Jim Blandy wrote: > 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 > okay. No, there are non-uniform address architectures where you can't simply increment or decrement a pointer without recalculating the values of the components of the address. > 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. 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. 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. On a NUMA system, a CORE_ADDR may well meet the requirement that it can address all memory. It doesn't meet the assumption that it is linear and contiguous. > 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. 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. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077