From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30273 invoked by alias); 25 Jul 2008 03:28:53 -0000 Received: (qmail 30264 invoked by uid 22791); 25 Jul 2008 03:28:52 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Jul 2008 03:28:35 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id B0F4A3C25C; Thu, 24 Jul 2008 20:28:33 -0700 (PDT) Subject: Re: Address spaces From: Michael Snyder To: Stan Shebs Cc: Doug Evans , gdb@sourceware.org In-Reply-To: <4887CCF2.6020503@codesourcery.com> References: <4887C7BD.80601@earthlink.net> <4887CCF2.6020503@codesourcery.com> Content-Type: text/plain Date: Fri, 25 Jul 2008 03:29:00 -0000 Message-Id: <1216956513.3549.536.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) 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: 2008-07/txt/msg00262.txt.bz2 On Wed, 2008-07-23 at 17:29 -0700, Stan Shebs wrote: > Doug Evans wrote: > > It would be useful to have proper address spaces for non-multi-process > > situations too. At the moment all one can do is hack in bits to > > unused parts of the address (assuming such bits are available ...). > > [I'm sure this isn't news. Just saying there are multiple reasons for > > addresses being more than just the CORE_ADDR of today, and if we solve > > one, let's at least consider the others too.] > > > Do you have some specific ideas in mind? Because I was assuming (and > this is good to be aware of) that there would not be more than one > address space associated with a process. Harvard architectures? Segmented architectures (intel real mode)? CS:deadbeef vs. DS:deadbeef? > (Instantly split I/D targets a > la D10V come to mind, although that was handled by distinguishing > pointers from addresses.) I have a half-recollection of doing a target that had a "code:" addr space and a "data:" addr space. Can't remember if that ever got contributed? Anyway, the idea of making CORE_ADDR a struct has been around for a long time. We've done our best to avoid it, but sort of always known it would come back one day.