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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Doug Evans wrote:

> > The problem arises when scheduler locking is switched on.  Actually,
> > I think there are really two problems.  First of all, after we've
> > switched back and single-stepped over an already-hit breakpoint via
> > the prepare_to_proceed logic, we'll continue only a single thread
> > if scheduler-locking is on -- and that is the wrong thread.  The
> > prepare_to_proceed logic only explicitly switches *back* to the
> > user-selected thread if the user was *stepping* (that's the
> > deferred_step_ptid logic).  For scheduler-locking, we should probably
> > switch back always ...
> 
> If scheduler locking is on, why is there any switching at all?  If
> scheduler-locking is on and I switch threads I'd want gdb to defer
> single-stepping the other thread over its breakpoint until the point
> when I make that other thread runnable.
> 
> Also, I think removing the notion of one previously stopped thread and
> generalizing it to not caring, i.e. checking the status of every
> stopped thread before resuming will simplify things and fix a few bugs
> along the way.  IOW, make deferred_ptid go away.

That may indeed be the best solution.  The simplest implementation
might be to simply remember in a per-thread flag the fact that the
last time this thread stopped, we reported a breakpoint at stop_pc
(which would have to be made per-thread as well, but we'd already
decided this should happen anyway).

This information could then be consulted the next time the thread
is made runnable again.

> > The second problem is more a problem of definition: even if the
> > first problem above were fixed, we've have to single-step the other
> > thread at least once to get over the breakpoint.  This would seem
> > to violate the definition of scheduler locking if interpreted
> > absolutely strictly.  Now you could argue that as the user should
> > never be aware of that single step, it doesn't really matter.
> 
> I'm not sure how we necessarily have a violation of the definition of
> scheduler locking.

This is just saying the same you said in other words: "If scheduler-
locking is on and I switch threads I'd want gdb to defer single-
stepping the other thread over its breakpoint until the point when
I make that other thread runnable."

I.e. "definition of scheduler locking" meaning: no other thread but
the one selected by the user runs, ever.  Today, this is not true,
in the case of single-stepping over a breakpoint in another thread.

Bye,
Ulrich

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