From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17293 invoked by alias); 28 Sep 2005 18:16:08 -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 17262 invoked by uid 22791); 28 Sep 2005 18:16:00 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 28 Sep 2005 18:16:00 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EKgTG-0003kw-LP; Wed, 28 Sep 2005 14:15:58 -0400 Date: Wed, 28 Sep 2005 18:16:00 -0000 From: Daniel Jacobowitz To: Andreas Schwab Cc: gdb-patches@sources.redhat.com Subject: Re: PR threads/2015: Fix adjust_pc_after_break for thread debugging Message-ID: <20050928181558.GA14304@nevyn.them.org> Mail-Followup-To: Andreas Schwab , gdb-patches@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00280.txt.bz2 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. I've got no objection. Mark asked you to test software single step and non-decr-pc-after-break; I agree with you that the patch can't have any effect if either of those is the case (see the context). So I think this is OK. Mark? I was worried about the case when the thread previously being stepped is not the event thread. But it seems to be OK and there are some problems there already (we don't keep track of whether the single-step succeeded or not in some cases, for instance). -- Daniel Jacobowitz CodeSourcery, LLC