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

[Doug Evans <dje at google dot com>]

Ping.

On Tue, Dec 2, 2008 at 3:40 AM, Doug Evans <dje@google.com> wrote:
> On Mon, Dec 1, 2008 at 7:46 PM, Doug Evans <dje@google.com> wrote:
>> On Mon, Dec 1, 2008 at 7:00 PM, Doug Evans <dje@google.com> wrote:
>>> Hi.  In http://sourceware.org/ml/gdb-patches/2008-11/msg00531.html
>>> I wrote:
>>>
>>>> I wrote a testcase that calls functions in multiple threads (with
>>>> scheduler-locking on) by setting a breakpoint on the function being
>>>> called.  I think there's a bug in scheduler-locking support as when I
>>>> make the second call in the second thread, gdb makes the first thread
>>>> step over the breakpoint and then resume, and control returns to
>>>> call_function_by_hand with inferior_ptid changed to the first thread.
>>>
>>> Here's a patch.
>>> This is separate from my dummy-frames cleanup patch.
>>>
>>> Ok to check in?
>>
>> Except of course nothing is ever this easy. :-(
>>
>> My testcase isn't complete:
>>
>> set scheduler-locking off
>> continue
>>
>> Adding the above to the end of the testcase reveals the fact that this
>> patch causes gdb to lose track of the fact that it needs to single
>> step over the breakpoint at all_threads_running in the main thread,
>> and resuming execution causes the breakpoint to be hit again.  Global
>> state, gotta love it.
>>
>> I'm assuming non-stop mode doesn't have this problem.
>> Can we record in struct thread_info (or some such) the last stop
>> reason and before resuming with !scheduler-locking iterate over all
>> threads, single stepping them as necessary?  Is there a better
>> solution?
>
> This patch fixes the expanded hand-call-in-threads.exp testcase (which
> is part of the patch).  In the process I discovered a bigger problem -
> gdb doesn't handle resuming after more than one thread is stopped at a
> breakpoint.  This can happen if the user runs several threads in turn
> with scheduler-locking on, and then turns scheduler-locking off and
> resumes the program.  I wrote another testcase,
> multi-bp-in-threads.exp, to expose this issue.  Fixing this appears to
> be a much harder problem, and I think I'd like to declare partial
> victory with this patch ...
>
> Comments?
>
> I have some questions.  Is it sufficient to test "thread->stop_signal
> == TRAP && breakpoint_here_p (pc)" to check if a thread is stopped at
> a breakpoint?  It seems to be.
>
> Another thing this revised patch does is stop SIGTRAP from being
> passed to the current thread to be run if it was received in the last
> thread that ran.  The comments say this is how gdb behaved before
> stop_signal was recorded for each thread.  It seems odd though.  If an
> asynchronous signal comes in and it is masked in some threads, if the
> kernel chooses a thread in which it's not blocked, should gdb be
> changing the thread that receives the signal?
> This patch takes a minimalist approach and only changes the behaviour
> of SIGTRAP.
>
> 2008-12-02  Doug Evans  <dje@google.com>
>
>        * infrun.c (prepare_to_proceed_callback): New function.
>        (prepare_to_proceed): Document.  Assert !non_stop.  Add debugging
>        printf.  If scheduler-locking is enabled, no other thread need to
>        be singlestepped.  Otherwise scan all threads for whether they're
>        stopped at a breakpoint instead of just the last thread that ran.
>        (proceed): Add FIXME.  Don't pass on TARGET_SIGNAL_TRAP from the
>        last thread that ran to the current thread to run.
>
>        * gdb.threads/hand-call-in-threads.exp: New file.
>        * gdb.threads/hand-call-in-threads.c: New file.
>        * gdb.threads/multi-bp-in-threads.exp: New file.
>        * gdb.threads/multi-bp-in-threads.c: New file.
>