From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-31418-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 9216 invoked by alias); 21 Mar 2008 05:58:16 -0000
Received: (qmail 9208 invoked by uid 22791); 21 Mar 2008 05:58:15 -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 05:57:58 +0000
Received: (qmail 3930 invoked from network); 21 Mar 2008 05:57:56 -0000
Received: from unknown (HELO localhost) (vladimir@127.0.0.2)   by mail.codesourcery.com with ESMTPA; 21 Mar 2008 05:57:56 -0000
From: Vladimir Prus <vladimir@codesourcery.com>
To: Nick Roberts <nickrob@snap.net.nz>
Subject: Re: MI non-stop mode spec
Date: Fri, 21 Mar 2008 09:48:00 -0000
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
Cc: "Marc Khouzam" <marc.khouzam@ericsson.com>,  gdb@sources.redhat.com
References: <200803190016.02072.vladimir@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA04290FB4@ecamlmw720.eamcs.ericsson.se> <18402.52910.383094.665060@kahikatea.snap.net.nz>
In-Reply-To: <18402.52910.383094.665060@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: <200803210858.01200.vladimir@codesourcery.com>
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2008-03/txt/msg00188.txt.bz2

On Thursday 20 March 2008 23:53:02 Nick Roberts wrote:
>  > >   -> Should @ varobjs be bound to only thread, or to nothing at
>  > > all.
>  >
>  > This is an interesting question.  It brings the possibility of
>  > supporting both those options.  That would mean three types of
>  > variable objects: 1- bound to a frame
>  > 2- bound to a thread
>  > 3- not bound
>
> 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? 
Furthermore, are (1) and (2) actually separate options? You cannot
evaluate varobj in a frame without also specifying a thread.

- Volodya