From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28852 invoked by alias); 5 Aug 2016 21:01:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 28843 invoked by uid 89); 5 Aug 2016 21:01:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=learn X-HELO: usplmg20.ericsson.net Received: from usplmg20.ericsson.net (HELO usplmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 05 Aug 2016 21:01:55 +0000 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id 99.5F.02568.73FF4A75; Fri, 5 Aug 2016 23:03:51 +0200 (CEST) Received: from [142.133.110.144] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.83) with Microsoft SMTP Server id 14.3.301.0; Fri, 5 Aug 2016 16:58:26 -0400 Subject: Re: [PATCH 1/2] mi: Restore original thread/frame when specifying --thread or --thread-group To: Pedro Alves , References: <20160801211401.18155-1-simon.marchi@ericsson.com> <20160801211401.18155-2-simon.marchi@ericsson.com> <155e8052-19b5-a446-c9bd-f973ded3eaa3@ericsson.com> <83adec9c-d7a1-3165-eac7-236372e994ef@redhat.com> <9a530702-6889-0d20-0a20-fcbce3cd57e2@ericsson.com> From: Simon Marchi Message-ID: <87789b60-69ed-c685-8058-15be519258eb@ericsson.com> Date: Fri, 05 Aug 2016 21:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00098.txt.bz2 On 16-08-05 01:26 PM, Pedro Alves wrote: > Yeah. The approach of extending the previous_inferior_ptid's scope a bit would > avoid this, since it wouldn't need to revert back anything with a cleanup. > Might end up being that once all the spots are identified, switching to > the other approach ends up being a simpler patch. Hmm maybe. I'll try to continue on that path and see what it gives. I really feel like I don't know what I am doing, but I'll try anyway, that's how we learn I suppose :). > Sounds like it. And don't we need a similar treatment for --frame ? I don't think we do. --frame can only be used with --thread, and if --thread is specified we will restore the state.