This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Fix hand called function when another thread has hit a bp.
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: dje at google dot com (Doug Evans)
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 17 Dec 2008 20:14:05 +0100 (CET)
- Subject: Re: [RFA] Fix hand called function when another thread has hit a bp.
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