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

[Doug Evans <dje@google.com>]

Ping.

On Mon, Feb 23, 2009 at 6:32 PM, Doug Evans <dje@google.com> wrote:
> On Wed, Dec 17, 2008 at 11:14 AM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
>> 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.
>
> Hi.  Here's an updated version of the patch.
> Handling the restart after several threads are all stopped at a
> breakpoint (via scheduler-locking = on), is left for a later patch
> (it's happens more rarely).
>
> Ok to check in?
>
> 2009-02-23  Doug Evans  <dje@google.com>
>
>        * infrun.c (prepare_to_proceed): Document.  Assert !non_stop.
>        If scheduler-locking is enabled, we're not going to be singlestepping
>        any other previously stopped thread.
>
>        * gdb.threads/hand-call-in-threads.exp: New file.
>        * gdb.threads/hand-call-in-threads.c: New file.
>