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

[Doug Evans <dje at google dot 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.
>>
>