From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1403 invoked by alias); 24 Jan 2007 10:42:59 -0000 Received: (qmail 1394 invoked by uid 22791); 24 Jan 2007 10:42:59 -0000 X-Spam-Check-By: sourceware.org Received: from vir-del-02.spheriq.net (HELO vir-del-02.spheriq.net) (194.50.41.41) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 Jan 2007 10:42:48 +0000 Received: from vir-out-01.spheriq.net ([194.50.41.30]) by vir-del-02.spheriq.net with ESMTP id l0OAgjq2013701 for ; Wed, 24 Jan 2007 10:42:45 GMT Received: from vir-cus-02.spheriq.net (vir-cus-02.spheriq.net [194.50.41.86]) by vir-out-01.spheriq.net with ESMTP id l0OAggYm028638 for ; Wed, 24 Jan 2007 10:42:42 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by vir-cus-02.spheriq.net with ESMTP id l0OAgdH5017759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 24 Jan 2007 10:42:42 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 50B22DA5E for ; Wed, 24 Jan 2007 10:42:32 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1E8DD47386 for ; Wed, 24 Jan 2007 10:42:30 +0000 (GMT) Received: from [164.129.44.95] (crx595.cro.st.com [164.129.44.95]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CJM49591 (AUTH "denis pilat"); Wed, 24 Jan 2007 11:42:27 +0100 (CET) Message-ID: <45B73813.9060005@st.com> Date: Wed, 24 Jan 2007 10:42:00 -0000 From: Denis PILAT User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: gdb-patches Cc: Denis PILAT Subject: Re: [RFC] thread apply commands change selected frame References: <45A61E73.8030400@st.com> <20070121173341.GG12463@nevyn.them.org> In-Reply-To: <20070121173341.GG12463@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2007-01/txt/msg00497.txt.bz2 Daniel Jacobowitz wrote: > On Thu, Jan 11, 2007 at 12:24:35PM +0100, Denis PILAT wrote: >> Hi everyone, >> >> I noticed a potential problem in thread.c: the "thread apply" commands >> change the selected frame, I think it should not. >> If you are doing >> (gdb) up >> (gdb) thread apply all print 1 >> (gdb) down >> then the frame selected before the up is not being restored by the down, >> we have an error message instead. > > Yeah, that's a strange behavior. > >> I need your opinion before going ahead in this patch. > > It looks right to me. With a ChangeLog entry and testsuite results > from some target with threads, it would be OK to commit. > There is one regression in the last test of gdb.threads/threadapply.exp since this test does not expect to get the stack frame. With my patch the current stack frame is alway printed at the end of a thread apply command. I also changed the semantic since I remove the print_stack_frame from the cleanup command so from the error treatment. I don't catch the original behaviour: it seems to print the stack frame only if the last thread we switched to (in the loop) is not the one we were before. In that case the user see that because he is in thread 2 before typing the command: (gdb) thread apply all p 1 [New Thread 1077955504 (LWP 27106)] Thread 3 (Thread 1077955504 (LWP 27106)): $1 = 1 Thread 2 (Thread 1075854256 (LWP 27105)): $2 = 1 Thread 1 (Thread 1073748160 (LWP 27045)): $3 = 1 12 fputc ('x', stderr); This last line is not printed if current thread is 1 before typing the command, that means 3 last line are always inconsistent. What behavior do we want in normal case (we retrieve the original thread) and in case where we can't since the thread has died for instance ? -- Denis