Re: [PATCH] Add call to prune_program_spaces in mi_cmd_remove_inferior

[Simon Marchi <simon.marchi@ericsson.com>]

On 2014-09-28 04:54 PM, Doug Evans wrote:
> 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.

It makes sense to me.

If we tie the creation/deletion of program spaces with the creation/deletion of
inferiors, could we go further and tie the concept of current program space and
current inferior? I see very often a set_current_inferior (inf) followed by a
set_current_program_space (inf->pspace). I don't really know when we would want
a current program space that is not the program space of our current inferior.

From what I can see, the only times set_current_program_space is called alone
is in constructs like this:

  old_chain = save_current_program_space ();
  ALL_PSPACES (ss)
  {
    set_current_program_space (ss);
    clear_section_table (current_target_sections);
    exec_close ();
  }
  do_cleanups (old_chain);

where exec_close accesses the global "current_program_space". So in reality,
it is passing a parameter indirectly using a global variable. I suppose we should
rather see:

  ALL_PSPACES (ss)
  {
    clear_section_table (current_target_sections);
    exec_close (ss);
  }

I realize that there is a lot of such indirect parameter passing in gdb. It
wouldn't be easy do to such a change, but I think it would help in many regards.