From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28047 invoked by alias); 2 Sep 2005 13:13:35 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28010 invoked by uid 22791); 2 Sep 2005 13:13:25 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 02 Sep 2005 13:13:25 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EBBMA-0003Ll-8n; Fri, 02 Sep 2005 09:13:22 -0400 Date: Fri, 02 Sep 2005 13:13:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: "info locals" -- is variable initialized Message-ID: <20050902131321.GA12830@nevyn.them.org> Mail-Followup-To: Vladimir Prus , gdb@sources.redhat.com References: <1125653235.9801.18.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00013.txt.bz2 On Fri, Sep 02, 2005 at 01:53:41PM +0400, Vladimir Prus wrote: > So, there's a window there variable does not exists according to C++, but > exists according to gdb. With better debug information, this doesn't happen (or the window is reduced to an instruction or two in the call sequence for the constructor). GCC 4's variable tracking feature does this passably well, IIRC, by use of dwarf2 location lists. In general no there is nothing gdb can do. -- Daniel Jacobowitz CodeSourcery, LLC