From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1625 invoked by alias); 21 Mar 2008 11:52:27 -0000 Received: (qmail 1616 invoked by uid 22791); 21 Mar 2008 11:52:26 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 21 Mar 2008 11:52:09 +0000 Received: (qmail 8992 invoked from network); 21 Mar 2008 11:52:06 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 21 Mar 2008 11:52:06 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: MI non-stop mode spec Date: Sat, 22 Mar 2008 00:33:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb@sources.redhat.com References: <200803190016.02072.vladimir@codesourcery.com> <200803210858.01200.vladimir@codesourcery.com> <18403.33887.752127.140905@kahikatea.snap.net.nz> In-Reply-To: <18403.33887.752127.140905@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803211307.50963.vladimir@codesourcery.com> 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/msg00191.txt.bz2 On Friday 21 March 2008 12:48:15 Nick Roberts wrote: > > > 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. Can you resend the current version of that patch, and I'll take a look. > > 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? There's also USE_SPECIFIED_FRAME, to make the whole thing funnier. Those values are only used in the call to varobj_create, and struct varobj has a field named 'use_selected_frame'. Probably the name of field of struct varobj is fine, whereas those USE_* are badly named indeed. Maybe, the varobj_create interface should be redone to accept a frame and a "floating" flag? > In general I guess threads don't traverse the same frames so watch > expressions wouldn't always work for all threads. Right, so when user switches UI to a different thread, we get to reevaluate watches. Something like: -var-update --thread 2 --frame 5 @ seems like appropriate solution. > 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. I think that the syntax mentioned above will get around that. When GDB evaluates -var-update --thread 2 --frame 5 @ it switches to thread (which selects frame 0) and then immediately selects frame 5, so by the time we evaluate expression, we're in the right thread and frame. - Volodya