From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-28228-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 10430 invoked by alias); 25 Mar 2007 12:03:35 -0000
Received: (qmail 10420 invoked by uid 22791); 25 Mar 2007 12:03:33 -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; Sun, 25 Mar 2007 13:03:30 +0100
Received: from kahikatea.snap.net.nz (184.61.255.123.dynamic.snap.net.nz [123.255.61.184]) 	by viper.snap.net.nz (Postfix) with ESMTP id 2FB183D9AA2; 	Mon, 26 Mar 2007 00:03:27 +1200 (NZST)
Received: by kahikatea.snap.net.nz (Postfix, from userid 500) 	id 7EDAC4F710; Mon, 26 Mar 2007 00:03:25 +1200 (NZST)
From: Nick Roberts <nickrob@snap.net.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17926.25867.185398.533328@kahikatea.snap.net.nz>
Date: Sun, 25 Mar 2007 12:03:00 -0000
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb@sources.redhat.com
Subject: Re: Behaviour of invalid varobjs
In-Reply-To: <200703251429.45714.ghost@cs.msu.su>
References: <etj4us$gif$1@sea.gmane.org> 	<200703221341.00513.ghost@cs.msu.su> 	<17923.5890.566302.505263@kahikatea.snap.net.nz> 	<200703251429.45714.ghost@cs.msu.su>
X-Mailer: VM 7.19 under Emacs 22.0.96.2
X-IsSubscribed: yes
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: 2007-03/txt/msg00306.txt.bz2

 > The testcase uses "**0", not *0, 

Presumably though we're not just interested in the tescase.

 > and I don't see any difference between constant and variable below:
 >... 
 > Can you clarify what you meant?

I can't seem to reproduce it now.  I must have been mistaken

 > >     Also, we probably should include in_scope="false" in output of
 > >     -var-create, but I'm not quite sure.
 > >
 > > I don't see why. 
 > 
 > Because as long as we (IMO, bogusly) use in_scope="false" to indicate
 > "expression cannot be evaluated", we should consistently report
 > that everywhere. 

AFAICS we don't use in_scope at all for -var-create.

-- 
Nick                                           http://www.inet.net.nz/~nickrob