From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7162 invoked by alias); 25 Jul 2008 18:50:22 -0000 Received: (qmail 7153 invoked by uid 22791); 25 Jul 2008 18:50:21 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Jul 2008 18:49:57 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id m6PIndTr011925; Fri, 25 Jul 2008 20:49:39 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id m6PIncKC025419; Fri, 25 Jul 2008 20:49:38 +0200 (CEST) Date: Fri, 25 Jul 2008 19:13:00 -0000 Message-Id: <200807251849.m6PIncKC025419@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: stanshebs@earthlink.net CC: msnyder@specifix.com, gdb@sourceware.org In-reply-to: <488A19D3.40706@earthlink.net> (message from Stan Shebs on Fri, 25 Jul 2008 11:22:11 -0700) Subject: Re: Address spaces References: <4887C7BD.80601@earthlink.net> <4887CCF2.6020503@codesourcery.com> <1216956513.3549.536.camel@localhost.localdomain> <488A19D3.40706@earthlink.net> 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/msg00273.txt.bz2 > Date: Fri, 25 Jul 2008 11:22:11 -0700 > From: Stan Shebs > > Michael Snyder wrote: > > 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. > > > Where my prototyping is evolving is to have a new type of object that is > the struct, tentatively called "target address", consisting of address > space + CORE_ADDR. From poking through all the references to CORE_ADDR, > it looks to me like 90%+ have an implicit single address space, so > structifying seems like an unnecessary nuisance. For instance, when > you're doing prologue analysis you're only going to be working in the > one address space (at least for non-Harvard). So I'm thinking higher > levels will pass around target addresses in a mostly-opaque way, then > when one gets down to working on a specific program / address space, the > CORE_ADDRs are extracted and used much as they are now. > > While not as abstractly elegant as making all addresses into objects > right off, it doesn't preclude us from going in that direction; someone > who wants to make a subsystem use target addresses instead of CORE_ADDRs > throughout could do so. Did you consider extending 'struct ptid' with an adress space identifier? In a way, POSIX processes already correspond to an address space, and the ptid is likely to be available in many places where you need to make the distinction.