From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10206 invoked by alias); 27 Sep 2005 22:24:03 -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 10162 invoked by uid 22791); 27 Sep 2005 22:23:53 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 27 Sep 2005 22:23:53 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EKNrb-00062L-Rw; Tue, 27 Sep 2005 18:23:51 -0400 Date: Tue, 27 Sep 2005 22:24:00 -0000 From: Daniel Jacobowitz To: Andreas Schwab , gdb-patches@sources.redhat.com Subject: Re: PR threads/2015: Fix adjust_pc_after_break for thread debugging Message-ID: <20050927222351.GB22753@nevyn.them.org> Mail-Followup-To: Andreas Schwab , gdb-patches@sources.redhat.com References: <20050927221952.GA22753@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050927221952.GA22753@nevyn.them.org> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00259.txt.bz2 On Tue, Sep 27, 2005 at 06:19:52PM -0400, Daniel Jacobowitz wrote: > On Wed, Sep 28, 2005 at 12:10:18AM +0200, Andreas Schwab wrote: > > adjust_pc_after_break is doing the wrong thing during thread debugging > > when the current thread is different from the thread when the debuggee was > > stopped last. The problem is that it calls currently_stepping, which > > accesses global variables that are part of the thread context. But the > > context switch will only happen much later on. The proposed fix will skip > > the call when the current infrun context does not match the thread to be > > examined. This has been tested on x86_64-suse-linux and fixes 32 > > testcases without any regressions. > > Which test failures are these? i.e. why doesn't anyone else see this > when they run the testsuite? > > Offhand I'd be suspicious that this helped - some other thread probably > needs its PC adjusted and now may not be. As a followup to my questions: it looks like the only globals which are used are also in ecs, so currently_stepping could easily be fixed to read only from ecs. But it's not clear whether we'd want to do this test on ecs, inferior_ptid, or both. -- Daniel Jacobowitz CodeSourcery, LLC