From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29938 invoked by alias); 1 Oct 2003 17:48:51 -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 29930 invoked from network); 1 Oct 2003 17:48:51 -0000 Received: from unknown (HELO artax.karlin.mff.cuni.cz) (195.113.31.125) by sources.redhat.com with SMTP; 1 Oct 2003 17:48:51 -0000 Received: by artax.karlin.mff.cuni.cz (Postfix, from userid 29129) id CE1E43FB0; Wed, 1 Oct 2003 19:48:50 +0200 (CEST) Date: Wed, 01 Oct 2003 17:48:00 -0000 From: Josef Zlomek To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Problem with location lists and variables on stack Message-ID: <20031001174850.GA24443@artax.karlin.mff.cuni.cz> References: <20031001144330.GA11707@artax.karlin.mff.cuni.cz> <20031001144937.GA4613@nevyn.them.org> <20031001154415.GA15387@artax.karlin.mff.cuni.cz> <20031001155417.GA13942@nevyn.them.org> <20031001160318.GA17042@artax.karlin.mff.cuni.cz> <20031001162255.GA25428@nevyn.them.org> <20031001174142.GA21499@artax.karlin.mff.cuni.cz> <20031001174427.GA13387@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031001174427.GA13387@nevyn.them.org> User-Agent: Mutt/1.5.4i X-SW-Source: 2003-10/txt/msg00038.txt.bz2 > > > The frame base is evaluated in the function's current context, not via > > > unwinding. So if GCC is using the CFA, then it needs to say so > > > somehow. It would be nice if it could reference the parent's stack > > > pointer somehow and save duplication. A mostly-relevant quote from the > > > spec: > > > > > > In the context of supporting nested subroutines, the DW_AT_frame_base > > > attribute value should obey the following constraints: > > > > > > 1. It should compute a value that does not change during the life of > > > the procedure, and > > > > So shall the location for all variables located on stack be reemitted with the > > changed offset after each push/pop? That would mean longer debug info. > > I thought better idea would be adjusting the offsets from frame base in GDB. > > No, but DW_AT_frame_base should be a location list describing the > changes in the frame base. I see. Thanks! Josef