Re: program spaces vs exec

[Pedro Alves <pedro@codesourcery.com>]

On Thursday 06 October 2011 19:59:30, Doug Evans wrote:
> 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]

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.

> 
> [...]
> 
> 
> >
> > > 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 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 symbols.

> 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, 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.

From 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.

-- 
Pedro Alves