From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10040 invoked by alias); 6 Oct 2011 19:35:15 -0000 Received: (qmail 9786 invoked by uid 22791); 6 Oct 2011 19:35:14 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_BJ X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 06 Oct 2011 19:34:59 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RBtic-0003az-8C from pedro_alves@mentor.com ; Thu, 06 Oct 2011 12:34:58 -0700 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Oct 2011 20:34:56 +0100 From: Pedro Alves To: Doug Evans Subject: Re: program spaces vs exec Date: Thu, 06 Oct 2011 19:35:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.1; x86_64; ; ) Cc: gdb@sourceware.org References: <20111005181526.B6CCA2461D1@ruffy.mtv.corp.google.com> <201110061251.22983.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201110062034.54262.pedro@codesourcery.com> 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/msg00036.txt.bz2 On Thursday 06 October 2011 19:59:30, Doug Evans wrote: > On Thu, Oct 6, 2011 at 4:51 AM, Pedro Alves wrot= e: >=20 > > 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? Or is there a functional reason? > > > > That preserved better how gdb behaved before there were > > multiple program spaces. E.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. For 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. I chose the latter approach originally. > > >=20 > So it seems like it was more just an implementation decision than somethi= ng > part of a design spec. > [just want to confirm I understood what you wrote correctly] What's a design spec? :-D The design was chosen for mirroring what gdb already did before. Before there was a `struct program_space' structure, you could say that all the symbol stuff was attached to a global and implicit program/symbol space. It just happened that the fields of the structure were scattered around the sources. >=20 > [...] >=20 >=20 > > > > > This concerns more than just exec of course. > > > E.g., Any time the "main" objfile is changed (e.g., "file foo") I'd > > intuitively > > > 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 progr= am > > space for this. > > >=20 > Huh. Does that have a use? > What if the new program uses a different ld.so? You could be doing "file my_executable_but_now_with_symbols", or even, you could have attached to an inferior without specifying the main executable, debugged the shared libraries (e.g., on Windows, it's perfectly fine to get the dll list without an executable --- the dll list is managed by the kernel, not userspace) -- set breakpoints, etc., and then load the main executable. It's all the same program/symbol space, you're just adding or taking describing pieces to or out of it. The contents of the program space change, but the program space entity/shell is the same. It's the same address space, but viewed with different symbol= s. > btw, I'm still not sure our definitions of program spaces match, and I th= ink > 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, than the program space is > changed as well by definition. > I gather this intuitive notion is incorrect. Yes, it seems like your definitions don't match. =46rom the comment at the top of progspace.h: > /* A program space represents a symbolic view of an address space. > Roughly speaking, it holds all the data associated with a > non-running-yet program (main executable, main symbols), and when > an inferior is running and is bound to it, includes the list of its > mapped in shared libraries. The shared libraries are part of the program/symbol space. For unix, you can think of the program space as the address space. "program" does not mean the main executable here, it means the "whole program's executable and shared libraries, basically everything that's mapped in the address space, an that we have info for". I had renamed "symbol space" to "program space" during submission as it was supposedly easier to understand that way. But it was just a rename. --=20 Pedro Alves