From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21600 invoked by alias); 25 Jun 2007 17:46:28 -0000 Received: (qmail 21590 invoked by uid 22791); 25 Jun 2007 17:46:27 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 25 Jun 2007 17:46:25 +0000 Received: (qmail 25210 invoked from network); 25 Jun 2007 17:46:23 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Jun 2007 17:46:23 -0000 To: Michael Eager 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> From: Jim Blandy Date: Mon, 25 Jun 2007 17:46:00 -0000 In-Reply-To: <467D9503.9060804@eagercon.com> (Michael Eager's message of "Sat, 23 Jun 2007 14:47:47 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00242.txt.bz2 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. 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. 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.