This is the mail archive of the 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 3/7] Force to insert software single step breakpoint

Pedro Alves <> writes:

> Another scenario occurred to me:
>  - Thread A is software single-stepping.
>  - Thread B hits single-step breakpoint of thread A.
>  - We pause all threads and set thread B stepping past the
>    single-step breakpoint of thread A.
> But if the single-step breakpoint is for another thread, then
> we won't actually manage to have thread B step past it, resulting
> in spurious re-hits and no-guaranteed forward progress.  See
> e.g., non-stop-fair-events.exp:
>         # On software single-step targets that don't support displaced
>         # stepping, threads keep hitting each others' single-step
>         # breakpoints, and then GDB needs to pause all threads to step
>         # past those.  The end result is that progress in the main
>         # thread will be slower and it may take a bit longer for the
>         # signal to be queued; bump the timeout.
> Sounds like we may need to look at the single-step breakpoint's thread 
> id, and only insert it if it is for the thread that is going to be 
> doing the step-over?  We may need to record that in step_over_info and 
> pass more info to stepping_past_instruction_at.

I think this is about any thread specific breakpoint, instead of
only single-step breakpoint (single-step breakpoint is thread specific
too).  If we are doing step-over for thread A, do we need to insert any
breakpoints specific to other threads?  (my answer is No).

Yao (éå)

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