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

[Doug Evans <dje at google dot com>]

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.

Attachment: gdb-081202-schedlock-2.patch.txt
Description: Text document