From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27179 invoked by alias); 1 Oct 2003 17:44:30 -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 27170 invoked from network); 1 Oct 2003 17:44:29 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 1 Oct 2003 17:44:29 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A4l1X-0003yT-AK; Wed, 01 Oct 2003 13:44:27 -0400 Date: Wed, 01 Oct 2003 17:44:00 -0000 From: Daniel Jacobowitz To: Josef Zlomek Cc: gdb@sources.redhat.com Subject: Re: Problem with location lists and variables on stack Message-ID: <20031001174427.GA13387@nevyn.them.org> Mail-Followup-To: Josef Zlomek , gdb@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031001174142.GA21499@artax.karlin.mff.cuni.cz> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00037.txt.bz2 On Wed, Oct 01, 2003 at 07:41:42PM +0200, Josef Zlomek wrote: > > What makes you believe that GDB is the problem? Here's the debug info > > for argument "g": > > > > <2><8e>: Abbrev Number: 3 (DW_TAG_formal_parameter) > > DW_AT_name : g > > DW_AT_decl_file : 1 > > DW_AT_decl_line : 4 > > DW_AT_type : > > DW_AT_location : 315 (location list) > > > > Here's the location list: > > 0000013b 00000000 00000017 (DW_OP_fbreg: 28) > > 0000013b 00000017 00000083 (DW_OP_reg3) > > 0000013b 00000083 00000087 (DW_OP_fbreg: 28) > > > > Here's the beginning of func1: > > 0x8048320 : push %ebp > > 0x8048321 : push %edi > > 0x8048322 : push %esi > > 0x8048323 : push %ebx > > 0x8048324 : sub $0x10,%esp > > 0x8048327 : mov 0x24(%esp,1),%eax > > 0x804832b : mov 0x2c(%esp,1),%edi > > 0x804832f : mov 0x38(%esp,1),%esi > > > > i.e. those pushes are not accounted for in the debug info. This is > > something that GCC must do when using -fomit-frame-pointer. > > I did not write the part generating the location lists, I do not know DRARF > much. I thought that the labels LCFIx after each push mean adjustment of the > frame pointer. > > .LVL0: > # basic block 0 > pushl %ebp > .LCFI0: > pushl %edi > .LCFI1: > pushl %esi They do. But they're not used for debug information (.debug_info); only for .debug_frame, which is _unwind_ information. > > To quote from the DWARF spec: > > > > The DW_OP_fbreg operation provides a signed LEB128 offset from the > > address specified by the location description in the > > DW_AT_frame_base attribute of the current function. (This is > > typically a "stack pointer" register plus or minus some offset. On > > more sophisticated systems it might be a location list that adjusts > > the offset according to changes in the stack pointer as the PC > > changes.) > > > > 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer