This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v3 09/17] Teach non-stop to do in-line step-overs (stop all, step, restart)


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 (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]