This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3 09/17] Teach non-stop to do in-line step-overs (stop all, step, restart)
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 21 Apr 2015 16:01:18 +0100
- Subject: Re: [PATCH v3 09/17] Teach non-stop to do in-line step-overs (stop all, step, restart)
- Authentication-results: sourceware.org; auth=none
- References: <1429267521-21047-1-git-send-email-palves at redhat dot com> <1429267521-21047-10-git-send-email-palves at redhat dot com>
Pedro Alves <palves@redhat.com> writes:
> - that adjust_pc_after_break doesn't end up confused. */
> - gdb_assert (sig != GDB_SIGNAL_0);
> + that adjust_pc_after_break doesn't end up confused.
> +
> + - In non-stop if we insert a breakpoint (e.g., a step-resume)
> + in one thread after another thread that was stepping had been
> + momentarily paused for a step-over. When we re-resume the
> + stepping thread, it may be resumed from that address with a
> + breakpoint that hasn't trapped yet. Seen with
> + gdb.threads/non-stop-fair-events.exp, on targets that don't
> + do displaced stepping. */
Does this comment mean the sequence like this?
thread B is paused,
a breakpoint is inserted at address PC for thread C,
thread B may be resumed from address PC
>
> +/* Select a thread at random, out of those which are resumed and have
> + had events. */
> +
> +static struct thread_info *
> +random_pending_event_thread (ptid_t waiton_ptid)
> +{
If GDB core knows select events at random, then we don't have to do
something similar in linux-nat.c:select_event_lwp, right?
--
Yao (éå)