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

[Doug Evans <dje@google.com>]

Ping.

On Fri, Mar 13, 2009 at 10:03 AM, Doug Evans <dje@google.com> wrote:
> 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.
>>
>