[PATCH 1/2] gdb: introduce 'all_non_exited_process_targets' and 'switch_to_target_no_thread'
Christian Biesinger
cbiesinger@google.com
Wed May 13 18:43:26 GMT 2020
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
More information about the Gdb-patches
mailing list