This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Fix hand called function when another thread has hit a bp.
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.
>