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: Simon Marchi <simon dot marchi at ericsson dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Mon, 29 Sep 2014 13:48:17 -0400
- 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> <CADPb22QABcOsUr7oN-=tHSryTUWiDx1E0fAGxV0zpARiWd+mAA at mail dot gmail dot 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.