Re: [RFA] Fix hand called function when another thread has hit a bp.

["Ulrich Weigand" <uweigand@de.ibm.com>]

Doug Evans wrote:

> >> Adding the above to the end of the testcase reveals the fact that this
> >> patch causes gdb to lose track of the fact that it needs to single
> >> step over the breakpoint at all_threads_running in the main thread,
> >> and resuming execution causes the breakpoint to be hit again.  Global
> >> state, gotta love it.
> >>
> >> I'm assuming non-stop mode doesn't have this problem.
> >> Can we record in struct thread_info (or some such) the last stop
> >> reason and before resuming with !scheduler-locking iterate over all
> >> threads, single stepping them as necessary?  Is there a better
> >> solution?
> >
> > This patch fixes the expanded hand-call-in-threads.exp testcase (which
> > is part of the patch).  In the process I discovered a bigger problem -
> > gdb doesn't handle resuming after more than one thread is stopped at a
> > breakpoint.  This can happen if the user runs several threads in turn
> > with scheduler-locking on, and then turns scheduler-locking off and
> > resumes the program.  I wrote another testcase,
> > multi-bp-in-threads.exp, to expose this issue.  Fixing this appears to
> > be a much harder problem, and I think I'd like to declare partial
> > victory with this patch ...

I'm not sure this is the right approach -- how can we be sure those
breakpoints in other threads have already been reported to the user?

The original code specifically steps only over the one breakpoint that
was reported when GDB last stopped.  If other threads hit breakpoints
simultaneously, we *want* them to trigger again, so that they can be
properly reported to the user ...

Why does this not work for your test case?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com