From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6631 invoked by alias); 1 Oct 2003 16:22:59 -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 6601 invoked from network); 1 Oct 2003 16:22:58 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 1 Oct 2003 16:22:58 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A4jke-0006eh-36; Wed, 01 Oct 2003 12:22:56 -0400 Date: Wed, 01 Oct 2003 16:22: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: <20031001162255.GA25428@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031001160318.GA17042@artax.karlin.mff.cuni.cz> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00033.txt.bz2 On Wed, Oct 01, 2003 at 06:03:18PM +0200, Josef Zlomek wrote: > > > > > Let the local variables and (some) arguments be addressed using stack pointer, > > > > > for example x86-64 architecture with variables addressed using %rsp. > > > > > The address emitted for variables located on stack by my new patch is always > > > > > DW_OP_fbreg + constant. > > > > > > > > > > When I was testing the emitted debug info with mainline GDB I found that > > > > > GDB probably does not adjust addresses of variables when stack pointer changes > > > > > (like because of "pushq" instruction) if using location lists. > > > > > I think GDB should adjust the address of %rsp addressed variables according to > > > > > change of %rsp (probably DWARF2 sais so for DW_OP_fbreg). I think it is a > > > > > better solution than emitting new locations to location list for all variables > > > > > located on stack after each "push" and "pop" which would cause too large debug > > > > > info. > > > > > > > > > > When I looked to gdb/dwarf2loc.c I see there: > > > > > /* FIXME: cagney/2003-03-26: This code should be using > > > > > get_frame_base_address(), and then implement a dwarf2 specific > > > > > this_base method. */ > > > > > Probably this is related to my problem. > > > > > > > > The FIXME is a cleanliness problem. We do evaluate DW_AT_frame_base, > > > > so it _ought_ to work. > > > > > > > > > I tested it on attached C file, assembler with debug info and x86-64 binary > > > > > is attached too. > > > > > > > > Do you suppose you could produce an x86 (ia32) testcase? I don't have > > > > x86-64 hardware available yet. The debug info looks right so I'd like > > > > to get my fingers into the problem. > > > > > > Here is the x86 assembler. > > > > Thanks. I'll get back to you... > > Thanks. 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. 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 > > > Blast! Location list support for paramaters (as opposed to locals) was > > added to GDB after 6.0 branched, and I never thought to move it over. > > It's too late now, so it will have to go in 6.0.1. > > No problem. > > Josef > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer