From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25106 invoked by alias); 30 Dec 2004 20:28:39 -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 24875 invoked from network); 30 Dec 2004 20:28:33 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 30 Dec 2004 20:28:33 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1Ck6uK-00033I-Nx; Thu, 30 Dec 2004 15:28:28 -0500 Date: Thu, 30 Dec 2004 20:28:00 -0000 From: Daniel Jacobowitz To: "H. J. Lu" Cc: gcc@gcc.gnu.org, GDB Subject: Re: Gdb generates location list without DW_AT_frame_base Message-ID: <20041230202828.GA11668@nevyn.them.org> Mail-Followup-To: "H. J. Lu" , gcc@gcc.gnu.org, GDB References: <20041222011627.GA15293@lucon.org> <41C9577D.3010509@redhat.com> <20041222182449.GA29407@lucon.org> <20041223034318.GA19580@nevyn.them.org> <20041230192424.GA16440@lucon.org> <20041230193618.GA16661@lucon.org> <20041230195642.GA16984@lucon.org> <20041230200720.GA11027@nevyn.them.org> <20041230202346.GA17311@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041230202346.GA17311@lucon.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-12/txt/msg00133.txt.bz2 On Thu, Dec 30, 2004 at 12:23:46PM -0800, H. J. Lu wrote: > On Thu, Dec 30, 2004 at 03:07:20PM -0500, Daniel Jacobowitz wrote: > > On Thu, Dec 30, 2004 at 11:56:42AM -0800, H. J. Lu wrote: > > > DW_AT_frame_base may be needed for location lists of local variables. > > > But in case of tls_symbolic_operand, there is no local variable. > > > Location lists are used for function parameters. > > > > Then why is GDB calling get_frame_base? It is only called for > > DW_OP_fbreg. If we don't have a frame base, we don't know what > > DW_OP_fbreg refers to. > > Gcc generates: > > <1><28c955>: Abbrev Number: 47 (DW_TAG_subprogram) > DW_AT_sibling : <28c98f> > DW_AT_external : 1 > DW_AT_name : (indirect string, offset: 0x3875d): > tls_symbolic_operand > DW_AT_decl_file : 1 > DW_AT_decl_line : 471 > DW_AT_prototyped : 1 > DW_AT_type : <2887cb> > DW_AT_low_pc : 0x826c1d0 > DW_AT_high_pc : 0x826c1fc > <2><28c96f>: Abbrev Number: 48 (DW_TAG_formal_parameter) > DW_AT_name : op > DW_AT_decl_file : 1 > DW_AT_decl_line : 470 > DW_AT_type : <288a7b> > DW_AT_location : 120fbf (location list) > <2><28c97e>: Abbrev Number: 49 (DW_TAG_formal_parameter) > DW_AT_name : (indirect string, offset: 0x3db66): mode > DW_AT_decl_file : 1 > DW_AT_decl_line : 470 > DW_AT_type : <288e5d> > DW_AT_location : 121018 (location list) > > for > > int > tls_symbolic_operand (rtx op, enum machine_mode mode ATTRIBUTE_UNUSED) > { > return ((GET_CODE (op) == SYMBOL_REF) && (SYMBOL_REF_TLS_MODEL (op) > != 0)) && (mode == VOIDmode || GET_MODE (op) == mode); > } > > It may be a gcc bug after all. And what's in the location lists? If it's DW_OP_fbreg, then I presume it's a GCC bug. According to my reading of the DWARF spec, anyway. -- Daniel Jacobowitz