From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13909 invoked by alias); 29 Feb 2004 04:02:11 -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 13883 invoked from network); 29 Feb 2004 04:02:05 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.170.238) by sources.redhat.com with SMTP; 29 Feb 2004 04:02:05 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id F0BA62B98; Sat, 28 Feb 2004 23:01:57 -0500 (EST) Message-ID: <40416435.7040706@gnu.org> Date: Sun, 29 Feb 2004 04:02:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [ob] Don't clobber inferior_ptid in read_pc_pid References: <20040228173541.GA15776@nevyn.them.org> <4040ECE7.8010607@gnu.org> <20040229031447.GA6234@nevyn.them.org> In-Reply-To: <20040229031447.GA6234@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00881.txt.bz2 > On Sat, Feb 28, 2004 at 02:32:55PM -0500, Andrew Cagney wrote: > >>>> >Another issue found in testing on arm-linux. A return was added to this >>>> >function back in June; if we return from the middle of it, we leave >>>> >inferior_ptid set to the wrong thread. This causes a "!ptid_equal >>>> >(ecs->ptid, inferior_ptid)" test to fail, since we called read_pc_pid >>>> >with ecs->ptid. That leads to not calling context_switch; which clobbers >>>> >the stepping range for the previous thread; which causes stepping to stop >>>> >unexpectedly. >>>> > >>>> >I'll commit this patch as obvious in a day or two. It isn't obvious, but it does appear to be correct. >>> Can you please commit it now? > > > Sorry, I had left before this message arrived. > > My goal in waiting was to retest on another target, which I did not > have time for this morning, and to wait for the release branch to be > confusion on my own part about the timing, since as of your > next-to-last announcement you were planning on back-dating the release > branch. These are patches I consider suitable for the release branch > and it's not much extra work for me to retest and commit them on two > branches. > > When I check in patches immediately people complain that I am acting > impetuously. When I wait you ask me to commit the patch now. When I > get back and see your message I get: My post clearly has context - if that change were committed before the branch was cut, life will be easy for all concerned. It doesn't say commit to an un-announced branch the moment you see the first hint that it is being created. That will make the release engineer's life hell. I'm going to alter the releng notes to point out that the first mention of the branch should be its announcement. That hopefully will stop future occurances of this problem. Andrew