From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 311 invoked by alias); 29 Mar 2009 04:32:22 -0000 Received: (qmail 300 invoked by uid 22791); 29 Mar 2009 04:32:21 -0000 X-SWARE-Spam-Status: No, hits=-1.9 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.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 29 Mar 2009 04:32:15 +0000 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id n2T4WCEh012707 for ; Sat, 28 Mar 2009 21:32:12 -0700 Received: from rv-out-0708.google.com (rvbl33.prod.google.com [10.140.88.33]) by zps37.corp.google.com with ESMTP id n2T4WB2G018422 for ; Sat, 28 Mar 2009 21:32:11 -0700 Received: by rv-out-0708.google.com with SMTP id l33so1869605rvb.30 for ; Sat, 28 Mar 2009 21:32:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.43.19 with SMTP id v19mr2016410rvj.226.1238301130990; Sat, 28 Mar 2009 21:32:10 -0700 (PDT) In-Reply-To: References: <200812171914.mBHJE61T002958@d12av02.megacenter.de.ibm.com> Date: Sun, 29 Mar 2009 13:36: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: quoted-printable 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/msg00655.txt.bz2 Ping. On Fri, Mar 13, 2009 at 10:03 AM, Doug Evans wrote: > Ping. > > On Mon, Feb 23, 2009 at 6:32 PM, Doug Evans wrote: >> On Wed, Dec 17, 2008 at 11:14 AM, Ulrich Weigand w= rote: >>> Doug Evans wrote: >>> >>>> > The problem arises when scheduler locking is switched on. =A0Actuall= y, >>>> > I think there are really two problems. =A0First 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. =A0The >>>> > 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). =A0For scheduler-locking, we should proba= bly >>>> > switch back always ... >>>> >>>> If scheduler locking is on, why is there any switching at all? =A0If >>>> 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. =A0IOW, make deferred_ptid go away. >>> >>> That may indeed be the best solution. =A0The 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. =A0This would seem >>>> > to violate the definition of scheduler locking if interpreted >>>> > absolutely strictly. =A0Now 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. =A0Today, this is not true, >>> in the case of single-stepping over a breakpoint in another thread. >> >> Hi. =A0Here's an updated version of the patch. >> Handling the restart after several threads are all stopped at a >> breakpoint (via scheduler-locking =3D on), is left for a later patch >> (it's happens more rarely). >> >> Ok to check in? >> >> 2009-02-23 =A0Doug Evans =A0 >> >> =A0 =A0 =A0 =A0* infrun.c (prepare_to_proceed): Document. =A0Assert !non= _stop. >> =A0 =A0 =A0 =A0If scheduler-locking is enabled, we're not going to be si= nglestepping >> =A0 =A0 =A0 =A0any other previously stopped thread. >> >> =A0 =A0 =A0 =A0* gdb.threads/hand-call-in-threads.exp: New file. >> =A0 =A0 =A0 =A0* gdb.threads/hand-call-in-threads.c: New file. >> >