Re: program spaces vs exec

[Doug Evans <dje@google.com>]

On Thu, Oct 6, 2011 at 4:51 AM, Pedro Alves <pedro@codesourcery.com> 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 = 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/resolve
> 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.

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 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 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" == "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.