From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20747 invoked by alias); 23 Jun 2007 21:25:45 -0000 Received: (qmail 20737 invoked by uid 22791); 23 Jun 2007 21:25:45 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 23 Jun 2007 21:25:43 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 2787D98180; Sat, 23 Jun 2007 21:25:42 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id C99C19817D; Sat, 23 Jun 2007 21:25:41 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1I2D7F-0000z6-Tv; Sat, 23 Jun 2007 17:25:57 -0400 Date: Sat, 23 Jun 2007 21:25:00 -0000 From: Daniel Jacobowitz To: Michael Eager Cc: gdb@sources.redhat.com Subject: Re: Non-uniform address spaces Message-ID: <20070623212557.GB3448@caradoc.them.org> Mail-Followup-To: Michael Eager , gdb@sources.redhat.com References: <467D4AE3.7020505@eagercon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467D4AE3.7020505@eagercon.com> User-Agent: Mutt/1.5.15 (2007-04-09) 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/msg00221.txt.bz2 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)? 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. -- Daniel Jacobowitz CodeSourcery