From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-28598-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 19574 invoked by alias); 23 May 2007 21:52:24 -0000
Received: (qmail 19563 invoked by uid 22791); 23 May 2007 21:52:23 -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; Wed, 23 May 2007 21:52:21 +0000
Received: (qmail 5040 invoked from network); 23 May 2007 21:52:20 -0000
Received: from unknown (HELO localhost) (jimb@127.0.0.2)   by mail.codesourcery.com with ESMTPA; 23 May 2007 21:52:20 -0000
To: Ross Morley <ross@tensilica.com>
Cc: Maxim Grigoriev <maxim@tensilica.com>,  gdb@sourceware.org, 	  Marc Gauthier <marc@tensilica.com>, 	  Pete MacLiesh <pmac@tensilica.com>
Subject: Re: Understanding GDB frames
References: <46521C04.7040405@hq.tensilica.com> 	<m3y7jgbt7j.fsf@codesourcery.com> <465341B8.9060208@hq.tensilica.com> 	<m3bqgc4d6g.fsf@codesourcery.com> <46538818.1050601@tensilica.com> 	<m3veektm5e.fsf@codesourcery.com> <4653A5F3.60503@tensilica.com>
From: Jim Blandy <jimb@codesourcery.com>
Date: Wed, 23 May 2007 21:52:00 -0000
In-Reply-To: <4653A5F3.60503@tensilica.com> (Ross Morley's message of "Tue, 22 May 2007 19:24:51 -0700")
Message-ID: <m34pm3rywc.fsf@codesourcery.com>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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-05/txt/msg00145.txt.bz2


Ross Morley <ross@tensilica.com> writes:
> We need to remember, though, that one goal is to minimize the overhead
> for the MI front end of having to re-create varobjs. As we get better
> at detecting a frame change (reduce false positives) we actually increase
> the overhead for the FE because it then (to be correct) needs to recreate
> its varobjs. We should think about solving that problem before we get too
> much better at detecting frame changes.

If you don't detect a frame change, then you're displaying garbage,
aren't you?  I'd expect fewer false positives should always be good...