From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18475 invoked by alias); 5 Jun 2003 19:04:09 -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 18457 invoked from network); 5 Jun 2003 19:04:09 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 5 Jun 2003 19:04:09 -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 h55J48H31056 for ; Thu, 5 Jun 2003 15:04:08 -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 h55J47T12718; Thu, 5 Jun 2003 15:04:07 -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 h55J46w31965; Thu, 5 Jun 2003 12:04:06 -0700 Message-ID: <3EDF9426.3B213ACB@redhat.com> Date: Thu, 05 Jun 2003 19:04: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> <3EDF8F94.27C60521@redhat.com> <20030605184723.GA15959@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00213.txt.bz2 Daniel Jacobowitz wrote: > > On Thu, Jun 05, 2003 at 11:44:36AM -0700, Michael Snyder wrote: > > 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... > > Well, I can't find any trace of it. For instance, on ARM it is > literally blatted into memory in arm_software_single_step. Ew. > > > > 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. > > Yeah. Do you think it's worthwhile to revisit this and investigate an > event scheduler in gdbserver also? Dunno -- you seem to be the main person working on gdbserver these days. ;-) Schedlock is user-settable. Maybe the SSS-schedlock behavior that you want should be user-settable too? Or maybe SSS targets could force a default to schedlock_step, and the user could cancel it if he wanted to?