From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19776 invoked by alias); 30 Dec 2004 20:23:57 -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 19369 invoked from network); 30 Dec 2004 20:23:47 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 30 Dec 2004 20:23:47 -0000 Received: from lucon.org ([24.6.212.230]) by comcast.net (rwcrmhc12) with ESMTP id <2004123020234601400r5fbse>; Thu, 30 Dec 2004 20:23:47 +0000 Received: by lucon.org (Postfix, from userid 1000) id A387E640F4; Thu, 30 Dec 2004 12:23:46 -0800 (PST) Date: Thu, 30 Dec 2004 20:23:00 -0000 From: "H. J. Lu" To: gcc@gcc.gnu.org, GDB Subject: Gdb generates location list without DW_AT_frame_base Message-ID: <20041230202346.GA17311@lucon.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041230200720.GA11027@nevyn.them.org> User-Agent: Mutt/1.4.1i X-SW-Source: 2004-12/txt/msg00132.txt.bz2 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. > > GDB should issue an error instead of crashing, but that's as far as we > can go. This patch does something like that --- dwarf2loc.c 2004-12-30 12:01:34.140350763 -0800 +++ dwarf2loc.c.new 2004-12-30 11:54:24.759408333 -0800 @@ -164,13 +164,16 @@ dwarf_expr_frame_base (void *baton, unsi *start = find_location_expression (symbaton, length, get_frame_pc (debaton->frame)); } - else + else if (SYMBOL_OPS (framefunc) == &dwarf2_locexpr_funcs) { struct dwarf2_locexpr_baton *symbaton; symbaton = SYMBOL_LOCATION_BATON (framefunc); *length = symbaton->size; *start = symbaton->data; } + else + error ("Invalid frame base function for \"%s\".", + SYMBOL_NATURAL_NAME (framefunc)); if (*start == NULL) error ("Could not find the frame base for \"%s\".", H.J.