Re: [PATCH 1/2] gdb: introduce 'all_non_exited_process_targets' and 'switch_to_target_no_thread'

[Christian Biesinger <cbiesinger@google.com>]

On Wed, May 13, 2020 at 3:26 AM Aktemur, Tankut Baris
<tankut.baris.aktemur@intel.com> wrote:
>
> On Wednesday, May 13, 2020 12:29 AM, Christian Biesinger wrote:
> > On Sun, May 3, 2020 at 10:37 AM Tankut Baris Aktemur via Gdb-patches
> > <gdb-patches@sourceware.org> wrote:
> > > @@ -83,3 +84,27 @@ process_stratum_target::has_execution (inferior *inf)
> > >       through hoops.  */
> > >    return inf->pid != 0;
> > >  }
> > > +
> > > +/* See process-stratum-target.h.  */
> > > +
> > > +std::set<process_stratum_target *>
> > > +all_non_exited_process_targets ()
> > > +{
> > > +  std::set<process_stratum_target *> targets;
> > > +  for (inferior *inf : all_non_exited_inferiors ())
> > > +    targets.insert (inf->process_target ());
> > > +
> > > +  return targets;
> >
> > Instead of creating a new set, it seems like it would be a lot more
> > efficient to just wrap the all_non_exited_inferiors() iterator and
> > return it->process_target(). What do you think?
>
> But the inferiors may share targets and this would not eliminate duplicates from
> appearing, would it?  We would still need a mechanism to remember the previously
> returned process targets and skip duplicates, I think.
>
> A remark about the code above is that the order of elements when iterating the set
> is not necessarily the same order we would get when iterating inferiors (i.e. the
> order of insertion into the set).  I don't think this matters, though.  And as long
> as a new target is not added to or removed from the debug session, the order obtained
> from each call to all_non_exited_process_targets is consistent.

Ah yes, that makes sense. Maybe add a comment that you're using set<>
to remove duplicates?

Christian