This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/7] Force to insert software single step breakpoint
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 13 Apr 2016 17:21:33 +0100
- Subject: Re: [PATCH 3/7] Force to insert software single step breakpoint
- Authentication-results: sourceware.org; auth=none
- References: <1458749384-19793-1-git-send-email-yao dot qi at linaro dot org> <1458749384-19793-4-git-send-email-yao dot qi at linaro dot org> <570BB52F dot 7 at redhat dot com>
Pedro Alves <palves@redhat.com> 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.
I finally managed to reproduce that thread id in step_over_info is
different from the thread id of the single-step breakpoint.
GDB now gives the high priority to finishing step over, to avoid
"threads keep hitting each others' single-step breakpoint". With my
patch applied, single-step breakpoint (of threads other than we are
stepping over) is still inserted even we try to step past the location,
so the step-over can't be finished.
>
> 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.
Yes, after I added a new field 'struct thread_info *thread' in
'struct step_over_info', I realize that IWBN to convert 'step_over_info'
to 'the thread we are stepping over', so the fields 'aspace' and 'address'
can be replaced by 'thread', like this,
struct step_over_info
{
struct thread_info *thread;
int nonsteppable_watchpoint_p;
};
Is it a good idea? If there is nothing obviously wrong, I'll post
patches to do this.
--
Yao (éå)