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: Mon, 29 Sep 2014 16:15:57 -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> <CADPb22QABcOsUr7oN-=tHSryTUWiDx1E0fAGxV0zpARiWd+mAA at mail dot gmail dot com> <54299B61 dot 7030107 at ericsson dot 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.