From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30055 invoked by alias); 14 Dec 2008 22:00:24 -0000 Received: (qmail 30045 invoked by uid 22791); 14 Dec 2008 22:00:23 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 14 Dec 2008 21:59:34 +0000 Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id mBELxWfV030541 for ; Sun, 14 Dec 2008 13:59:32 -0800 Received: from rv-out-0506.google.com (rvbf9.prod.google.com [10.140.82.9]) by wpaz1.hot.corp.google.com with ESMTP id mBELxU3R020701 for ; Sun, 14 Dec 2008 13:59:30 -0800 Received: by rv-out-0506.google.com with SMTP id f9so611688rvb.5 for ; Sun, 14 Dec 2008 13:59:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.89.13 with SMTP id r13mr3292046rvl.271.1229291969845; Sun, 14 Dec 2008 13:59:29 -0800 (PST) In-Reply-To: References: <20081202030036.C2C201C7A0B@localhost> Date: Sun, 14 Dec 2008 22:00:00 -0000 Message-ID: Subject: Re: [RFA] Fix hand called function when another thread has hit a bp. From: Doug Evans To: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00267.txt.bz2 Ping. On Tue, Dec 2, 2008 at 3:40 AM, Doug Evans wrote: > On Mon, Dec 1, 2008 at 7:46 PM, Doug Evans wrote: >> On Mon, Dec 1, 2008 at 7:00 PM, Doug Evans 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 > > * 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. >