This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: program spaces vs exec


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]