program spaces vs exec

program spaces vs exec

[Doug Evans]

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?

I ask because, for example, registering pretty-printers
with a particular progspace doesn't work as one would expect
in this case.  E.g., One needs the pretty-printers from the
previous program to be gone when the new one loads.

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.

OTOH, it's entirely possible progspaces need to be looked at differently
for *nix.

For reference sake, from the archives I found this:
http://sourceware.org/ml/gdb-patches/2009-10/msg00110.html

Re: program spaces vs exec

[Pedro Alves]

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.

> I ask because, for example, registering pretty-printers
> with a particular progspace doesn't work as one would expect
> in this case.  E.g., One needs the pretty-printers from the
> previous program to be gone when the new one loads.

Not sure the program space is the real problem.  How do pretty-printers
from a shared library that unloads go away?  We should treat
pretty printers of the main program and pretty printers of 
shared libraries similarly.

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

-- 
Pedro Alves

Re: program spaces vs exec

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> E.g., breakpoints are supposed to reset/resolve after the exec,
Pedro> and since the breakpoint symbol search scope is currently tied to
Pedro> a program space, keeping the same program space keeps that
Pedro> working the same.

FWIW, I'm changing this.

Pedro>  For exec, I don't have a strong feeling either way, we could say
Pedro> that there's a new address/program space attached to the
Pedro> inferior, or we could say that the inferior's address/program
Pedro> spaces have been refreshed with a new set of pages.  I chose the
Pedro> latter approach originally.

I think it would be fine to reset the pretty-printers at this point.

Pedro> How do pretty-printers from a shared library that unloads go
Pedro> away?

Generally they are attached to the objfile.  So, they disappear
automatically when the objfile is removed.

Tom

Re: program spaces vs exec

[Pedro Alves]

On Thursday 06 October 2011 19:22:38, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> 
> Pedro> E.g., breakpoints are supposed to reset/resolve after the exec,
> Pedro> and since the breakpoint symbol search scope is currently tied to
> Pedro> a program space, keeping the same program space keeps that
> Pedro> working the same.
> 
> FWIW, I'm changing this.

Yeah, I assumed so.  For watchpoints too though, or just things
with linespecs?

> Pedro>  For exec, I don't have a strong feeling either way, we could say
> Pedro> that there's a new address/program space attached to the
> Pedro> inferior, or we could say that the inferior's address/program
> Pedro> spaces have been refreshed with a new set of pages.  I chose the
> Pedro> latter approach originally.
> 
> I think it would be fine to reset the pretty-printers at this point.

But aren't we already?  We get rid of the executable and all the
shared libraries at this point.

> Pedro> How do pretty-printers from a shared library that unloads go
> Pedro> away?
> 
> Generally they are attached to the objfile.  So, they disappear
> automatically when the objfile is removed.

There must be something more to the issue then.  Both "file foo" or
an exec get rid of the previous executable's symfile_objfile and
create a new one too, so the executable's printers must already be
being removed.

-- 
Pedro Alves

Re: program spaces vs exec

[Doug Evans]

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.

Re: program spaces vs exec

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Tom> FWIW, I'm changing this.

Pedro> Yeah, I assumed so.  For watchpoints too though, or just things
Pedro> with linespecs?

Just linespecs.

Tom

Re: program spaces vs exec

[Tom Tromey]

Forgot to reply to part...

Pedro> How do pretty-printers from a shared library that unloads go
Pedro> away?

Tom> Generally they are attached to the objfile.  So, they disappear
Tom> automatically when the objfile is removed.

Pedro> There must be something more to the issue then.  Both "file foo" or
Pedro> an exec get rid of the previous executable's symfile_objfile and
Pedro> create a new one too, so the executable's printers must already be
Pedro> being removed.

That would work if the printer was attached to the executable's objfile;
but you can also attach a printer to a program space, which is the
problem case.

Tom

Re: program spaces vs exec

[Pedro Alves]

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

Re: program spaces vs exec

[Pedro Alves]

On Thursday 06 October 2011 20:34:48, Tom Tromey wrote:
> Forgot to reply to part...
> 
> Pedro> How do pretty-printers from a shared library that unloads go
> Pedro> away?
> 
> Tom> Generally they are attached to the objfile.  So, they disappear
> Tom> automatically when the objfile is removed.
> 
> Pedro> There must be something more to the issue then.  Both "file foo" or
> Pedro> an exec get rid of the previous executable's symfile_objfile and
> Pedro> create a new one too, so the executable's printers must already be
> Pedro> being removed.
> 
> That would work if the printer was attached to the executable's objfile;
> but you can also attach a printer to a program space, which is the
> problem case.

Then this isn't just about execs indeed, and I don't understand
the usefulness of attaching a printer to the program space.
The program space is the same even if you run -> kill -> run -> `attach to some
other process running some other program' -> kill -> "target remote :9999" ->
etc.

-- 
Pedro Alves

Re: program spaces vs exec

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> Then this isn't just about execs indeed, and I don't understand
Pedro> the usefulness of attaching a printer to the program space.

I don't remember the rationale, Doug would have to answer that.

Tom

Re: program spaces vs exec

[Doug Evans]

On Thu, Oct 6, 2011 at 12:41 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> The program space is the same even if you run -> kill -> run -> `attach to some
> other process running some other program' -> kill -> "target remote :9999" ->
> etc.

Eh?

I would say all of those are different program spaces.