From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16413 invoked by alias); 22 May 2007 16:36:28 -0000 Received: (qmail 16355 invoked by uid 22791); 22 May 2007 16:36:27 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 May 2007 16:36:19 +0000 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id 916FA4B267; Tue, 22 May 2007 11:36:17 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id 6F64E4B262; Tue, 22 May 2007 11:36:17 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1HqXLM-0006hO-VZ; Tue, 22 May 2007 12:36:16 -0400 Date: Tue, 22 May 2007 16:36:00 -0000 From: Daniel Jacobowitz To: Marc Gauthier Cc: Ross Morley , Nick Roberts , Maxim Grigoriev , gdb@sourceware.org, Pete MacLiesh Subject: Re: Understanding GDB frames Message-ID: <20070522163616.GB25392@caradoc.them.org> Mail-Followup-To: Marc Gauthier , Ross Morley , Nick Roberts , Maxim Grigoriev , gdb@sourceware.org, Pete MacLiesh References: <4652AC74.9050100@tensilica.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-09) 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: 2007-05/txt/msg00111.txt.bz2 On Tue, May 22, 2007 at 09:10:29AM -0700, Marc Gauthier wrote: > As we discussed offline yesterday, this has performance implications > on the GUI, which would have to recreate the varobjs every time which > is time consuming. Is the performance implication the main reason? If so, I'd rather we fix that instead. I know Nick and/or Vladimir suggested "-var-list --locals" at one point in an earlier discussion of a related problem. That's probably quite a lot faster, especially if we can notify the front end when it enters a new frame. -- Daniel Jacobowitz CodeSourcery