This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
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