From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30597 invoked by alias); 13 Mar 2009 17:04:02 -0000 Received: (qmail 30539 invoked by uid 22791); 13 Mar 2009 17:04:00 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 Mar 2009 17:03:55 +0000 Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id n2DH3pgh022434 for ; Fri, 13 Mar 2009 17:03:51 GMT Received: from rv-out-0506.google.com (rvbl9.prod.google.com [10.140.88.9]) by wpaz17.hot.corp.google.com with ESMTP id n2DH3ffJ009425 for ; Fri, 13 Mar 2009 10:03:50 -0700 Received: by rv-out-0506.google.com with SMTP id l9so1673037rvb.9 for ; Fri, 13 Mar 2009 10:03:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.53.1 with SMTP id f1mr668342rvk.6.1236963829711; Fri, 13 Mar 2009 10:03:49 -0700 (PDT) In-Reply-To: References: <200812171914.mBHJE61T002958@d12av02.megacenter.de.ibm.com> Date: Fri, 13 Mar 2009 17:06:00 -0000 Message-ID: Subject: Re: [RFA] Fix hand called function when another thread has hit a bp. From: Doug Evans To: Ulrich Weigand , gdb-patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true 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: 2009-03/txt/msg00211.txt.bz2 Ping. On Mon, Feb 23, 2009 at 6:32 PM, Doug Evans wrote: > On Wed, Dec 17, 2008 at 11:14 AM, Ulrich Weigand 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 > > * 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. >