From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29474 invoked by alias); 25 Jul 2008 19:13:43 -0000 Received: (qmail 29466 invoked by uid 22791); 25 Jul 2008 19:13:43 -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; Fri, 25 Jul 2008 19:13:21 +0000 Received: (qmail 5858 invoked from network); 25 Jul 2008 19:13:19 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Jul 2008 19:13:19 -0000 Message-ID: <488A25C9.3010601@codesourcery.com> Date: Fri, 25 Jul 2008 19:24:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Mark Kettenis CC: msnyder@specifix.com, gdb@sourceware.org Subject: Re: Address spaces References: <4887C7BD.80601@earthlink.net> <4887CCF2.6020503@codesourcery.com> <1216956513.3549.536.camel@localhost.localdomain> <488A19D3.40706@earthlink.net> <200807251849.m6PIncKC025419@brahms.sibelius.xs4all.nl> In-Reply-To: <200807251849.m6PIncKC025419@brahms.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00274.txt.bz2 Mark Kettenis wrote: >> 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. > Struct ptid is handy, but by nature it's tied to running inferiors, seems like it would be a little out of place if we needed it to to look at execs and symbol files before running. Stan