Re: [PATCH] Add call to prune_program_spaces in mi_cmd_remove_inferior

[Doug Evans <dje@google.com>]

On Mon, Sep 29, 2014 at 10:48 AM, Simon Marchi
<simon.marchi@ericsson.com> wrote:
> [...]
> 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.

This would be nice alright.
There are special cases, which we can handle in whatever way works,
but IWBN if this was the normal way of maintaining such state -
anytime we can remove unnecessary global state "works for me".

> 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);

current_target_sections is actually a member of the
current_program_space, so this could be improved even more (gotta love
macros ...).

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

Agreed!
I think it's a longterm todo on everyone's list.