From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1867 invoked by alias); 5 Jun 2003 18:44:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1851 invoked from network); 5 Jun 2003 18:44:38 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 5 Jun 2003 18:44:38 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h55IibH22208 for ; Thu, 5 Jun 2003 14:44:37 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h55IiaT11913; Thu, 5 Jun 2003 14:44:36 -0400 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h55Iiaw29729; Thu, 5 Jun 2003 11:44:36 -0700 Message-ID: <3EDF8F94.27C60521@redhat.com> Date: Thu, 05 Jun 2003 18:44:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: RFC: Always use at least schedlock_step for software single step targets References: <20030605143728.GA31355@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00208.txt.bz2 Daniel Jacobowitz wrote: > > This deserves a bit of explanation. Andrew, this is the same bug I was > telling you about in the hallway at the Summit. The fix is a bit different, > though. > > Our threading test results have always been fairly bad on targets which use > software single step. One reason was that we didn't properly associate the > single-step breakpoint with a thread. We didn't? I thought a single-step breakpoint was always thread-specific? Pretty sure it used to be... > So if another thread hit it before > the expected one, then that thread would get a SIGTRAP. Oops. Worse, if I > set up thread hopping we'd lose the fact that we were originally > single-stepping a different thread, and lose control of the inferior. > > I put together a patch to fix both of these. It was pretty gross, so I'm > not including it here, but it worked. It had a different problem, however: > we livelock in schedlock.exp because other threads always hit the breakpoint > before the one we're trying to step. A similar problem was solved in > lin-lwp by an ad-hoc scheduler, if I recall correctly. I concluded that the > tradeoffs for implementing this sort of scheduler on a remote stub were too > high, and used this patch instead. If we're inserting a software single > step breakpoint, be sure to resume only one thread. > > Thoughts? It effectively forces schedlock_step for SSS targets (but I guess you knew that). People appear to be very diverse in their opinion about whether schedlock is the "right" behavior or the "wrong" one. You might not see the behavior that you're trying to debug, if you're only stepping one thread. > 2003-06-05 Daniel Jacobowitz > > * infrun.c (resume): Always assume schedlock_step for > software single step. > > Index: infrun.c > =================================================================== > RCS file: /cvs/src/src/gdb/infrun.c,v > retrieving revision 1.109 > diff -u -p -r1.109 infrun.c > --- infrun.c 7 May 2003 18:35:57 -0000 1.109 > +++ infrun.c 5 Jun 2003 14:30:43 -0000 > @@ -625,10 +625,11 @@ resume (int step, enum target_signal sig > } > > if ((scheduler_mode == schedlock_on) || > - (scheduler_mode == schedlock_step && > - (step || singlestep_breakpoints_inserted_p))) > + (scheduler_mode == schedlock_step && step) > + || singlestep_breakpoints_inserted_p) > { > /* User-settable 'scheduler' mode requires solo thread resume. */ > + /* Software single-step doesn't work right with multiple threads. */ > resume_ptid = inferior_ptid; > } >