This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Add call to prune_program_spaces in mi_cmd_remove_inferior
- From: Doug Evans <dje at google dot com>
- To: Simon Marchi <simon dot marchi at ericsson dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Sun, 28 Sep 2014 13:54:53 -0700
- Subject: Re: [PATCH] Add call to prune_program_spaces in mi_cmd_remove_inferior
- Authentication-results: sourceware.org; auth=none
- References: <1411593539-6507-1-git-send-email-simon dot marchi at ericsson dot com> <CADPb22RUCDTyQd0qtJBcJX56mpk4C_RjZn3pRobKXFHBCnc42w at mail dot gmail dot com> <54242FBD dot 7030408 at ericsson dot com> <CADPb22RP0LH96jDz_BSGaDaGtkuyvLoS=p0A2BVN7KHNacnYJQ at mail dot gmail dot com>
On Sun, Sep 28, 2014 at 1:16 PM, Doug Evans <dje@google.com> wrote:
>[...]
> btw #2, There's also the invariant "There's always (at least) one
> program space."
> One is left with the question of whether they could be unrelated.
> IOW could there be an inferior without a program space or a program
> space without an inferior?
> [At least in general. There are special cases where we do temporary
> hacks to get through forks and such.]
> Another cleanup could be to make this clearer.
One thought I had, and I'm just thinking out loud here, is to rephrase
this invariant as "An inferior always has a program space." Then,
given that there is always an inferior, it falls out that there will
also always be a program space.
But, at least to this reader, program spaces can't ever be thought of
as being created on their own, they are only created when an inferior
is created, and deleted when the last inferior using it is deleted.
That includes the initial program space, which leads to the thought of
merging the creation of the initial program space and initial
inferior.
Doing that feels clearer to me than initializing them separately,
given that we're going to be actively deleting program spaces when the
last-using inferior is deleted.