From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13764 invoked by alias); 21 Mar 2008 09:48:54 -0000 Received: (qmail 13750 invoked by uid 22791); 21 Mar 2008 09:48:53 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 21 Mar 2008 09:48:23 +0000 Received: from kahikatea.snap.net.nz (102.63.255.123.dynamic.snap.net.nz [123.255.63.102]) by viper.snap.net.nz (Postfix) with ESMTP id C16183D9C4A; Fri, 21 Mar 2008 22:48:19 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id AFC578FC6D; Fri, 21 Mar 2008 21:48:16 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18403.33887.752127.140905@kahikatea.snap.net.nz> Date: Fri, 21 Mar 2008 18:13:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI non-stop mode spec In-Reply-To: <200803210858.01200.vladimir@codesourcery.com> References: <200803190016.02072.vladimir@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA04290FB4@ecamlmw720.eamcs.ericsson.se> <18402.52910.383094.665060@kahikatea.snap.net.nz> <200803210858.01200.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.1.92.2 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00190.txt.bz2 > > I think there are more than three possibilities: > > > > 1) bound to the frame in which varobj is created (*). > > 2) bound to the selected frame (@) > > 3) bound to the thread in which varobj is created and 1) > > 4) bound to the thread in which varobj is created and 2) > > 5) bound to the selected thread and 1) > > 6) bound to the selected thread and 2) > > > > Maybe there are more, e.g, all threads (I've not really thought them > > through) > > > > Currently only 1) works and 2) has a broken implementation. > > Didn't you check in a patch to make *-varobjs be found to a thread? I submitted a patch earlier this year that stopped thinking that a variable object had gone out of scope if the thread changed but nothing happened. > Furthermore, are (1) and (2) actually separate options? You cannot > evaluate varobj in a frame without also specifying a thread. Hmm, perhaps I typed that too quickly, it looks like 3-6 are just multi-threaded cases of 1 and 2, so there are four in total. It appears that Totalview call 1) FIXED compilation scope and 2) FLOATING compilation scope. Gdb calls it USE_CURRENT_FRAME and USE_SELECTED_FRAME which I find very confusing. Particularly (as I've said before) the manual mixes the meaning of current frame with selected frame. With USE_SELECTED_FRAME, the value can change without execution, e.g. after an up or down. It would be nice to change these enum values to USE_FIXED_FRAME and USE_FLOATING_FRAME. WDYT? In general I guess threads don't traverse the same frames so watch expressions wouldn't always work for all threads. I don't know how GDB would know if they did but I see that Totalview has something that they call a laminated view which views variables across threads (and processes). In fact their online manual must be a good guideline for some of the non-stop mode spec. Also GDB loses sense of the selected frame: if you change to a different thread and back again you always get back to the innermost (= current) frame. So that makes it difficult to get USE_SELECTED_FRAME to work in the multi-threaded case. -- Nick http://www.inet.net.nz/~nickrob