From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18687 invoked by alias); 6 Oct 2011 19:05:09 -0000 Received: (qmail 18666 invoked by uid 22791); 6 Oct 2011 19:05:06 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 06 Oct 2011 19:04:40 +0000 Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p96J4dlK009447 for ; Thu, 6 Oct 2011 12:04:39 -0700 Received: from qadc14 (qadc14.prod.google.com [10.224.32.142]) by wpaz37.hot.corp.google.com with ESMTP id p96J0K0A020026 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 6 Oct 2011 12:04:38 -0700 Received: by qadc14 with SMTP id c14so5300570qad.10 for ; Thu, 06 Oct 2011 12:04:38 -0700 (PDT) Received: by 10.224.184.137 with SMTP id ck9mr818648qab.111.1317927878345; Thu, 06 Oct 2011 12:04:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.184.137 with SMTP id ck9mr818643qab.111.1317927878214; Thu, 06 Oct 2011 12:04:38 -0700 (PDT) Received: by 10.224.80.149 with HTTP; Thu, 6 Oct 2011 12:04:38 -0700 (PDT) In-Reply-To: <201110061251.22983.pedro@codesourcery.com> References: <20111005181526.B6CCA2461D1@ruffy.mtv.corp.google.com> <201110061251.22983.pedro@codesourcery.com> Date: Thu, 06 Oct 2011 19:05:00 -0000 Message-ID: Subject: Re: program spaces vs exec From: Doug Evans To: Pedro Alves Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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: 2011-10/txt/msg00033.txt.bz2 On Thu, Oct 6, 2011 at 4:51 AM, Pedro Alves wrote: > > On Wednesday 05 October 2011 19:15:26, Doug Evans wrote: > > Hi. > > > > Question: Why does the program space remain unchanged across an exec? > > [for reference sake, target =3D amd64-linux] > > > > Is it just expediency? =A0Or is there a functional reason? > > That preserved better how gdb behaved before there were > multiple program spaces. =A0E.g., breakpoints are supposed to reset/resol= ve > after the exec, and since the breakpoint symbol search scope is > currently tied to a program space, keeping the same program space > keeps that working the same. =A0For exec, I don't have a strong > feeling either way, we could say that there's a new address/program > space attached to the inferior, or we could say that the inferior's > address/program spaces have been refreshed with a new set of > pages. =A0I chose the latter approach originally. So it seems like it was more just an implementation decision than something part of a design spec. [just want to confirm I understood what you wrote correctly] [...] > > This concerns more than just exec of course. > > E.g., Any time the "main" objfile is changed (e.g., "file foo") I'd int= uitively > > expect a new program space. > > Changing the main file does not necessarily invalidate or get rid of the > loaded shared library list, so I think we should not create a new program > space for this. Huh. Does that have a functional use (as distinct from, e.g., an optimization-use)? [in the context of amd64-linux, et.al.] What if the new program uses a different ld.so? btw, I'm still not sure our definitions of program spaces match, and I think we need to fix that first. According to previous emails from you, e.g. the one I mentioned, "program space" =3D=3D "symbol space". Intuitively, if the symbol space is changed, then the program space is changed as well by definition. If I change the main program that, to me, changes the symbol space. I gather this intuitive notion is incorrect.