From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27986 invoked by alias); 23 Jun 2007 21:47:56 -0000 Received: (qmail 27977 invoked by uid 22791); 23 Jun 2007 21:47:55 -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; Sat, 23 Jun 2007 21:47:53 +0000 Received: (qmail 7790 invoked from network); 23 Jun 2007 14:47:51 -0700 Received: from 209-128-106-254.bayarea.net (HELO ?192.168.20.7?) (209.128.106.254) by shell4.bayarea.net with SMTP; 23 Jun 2007 14:47:51 -0700 Message-ID: <467D9503.9060804@eagercon.com> Date: Sat, 23 Jun 2007 21:47:00 -0000 From: Michael Eager User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Michael Eager , gdb@sources.redhat.com Subject: Re: Non-uniform address spaces References: <467D4AE3.7020505@eagercon.com> <20070623212557.GB3448@caradoc.them.org> In-Reply-To: <20070623212557.GB3448@caradoc.them.org> 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/msg00224.txt.bz2 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 thought most of the HA systems just increased the address size by one bit and had the high-order bit specify whether the address was in D or I address space. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077