From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10775 invoked by alias); 5 Dec 2006 11:34:40 -0000 Received: (qmail 10765 invoked by uid 22791); 5 Dec 2006 11:34:38 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,TW_YP X-Spam-Check-By: sourceware.org Received: from ns2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 05 Dec 2006 11:34:32 +0000 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 09CBF20F49; Tue, 5 Dec 2006 12:34:29 +0100 (CET) Date: Tue, 05 Dec 2006 17:20:00 -0000 From: Jan Blunck To: "Frank Ch. Eigler" Cc: systemtap@sources.redhat.com Subject: Re: [BUG?] semantic error: failed to retrieve location attribute for local Message-ID: <20061205113428.GC10309@hasse.suse.de> References: <20061204115635.GB10309@hasse.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00601.txt.bz2 On Mon, Dec 04, Frank Ch. Eigler wrote: > > The full error message is as follows: > > [...] > > querying entrypc c0170197 of instance of inline 'real_lookup' > > probe real_lookup@fs/namei.c:447 kernel section=.text pc=0xc0170197 > > finding location for local 'parent' near address c0170197, module bias 0 > > finding location for local 'name' near address c0170197, module bias 0 > > [...] > > semantic error: failed to retrieve location attribute for local 'name' > > (dieoffset: 85127198053): identifier '$name' at real_lookup.stp:9:20 > > [...] > > Is this a bug? > > Problems such as this tend to be limitations of gcc debugging > information quality. One frequently-hit bug is that few actual > parameters get proper debugging information emitted, even if they are > used by the inlined function body. This is a major problem. A lot of interesting code is inlined in the kernel. Any plans/ideas how to fix this issue? But the debuginfo is emitted AFAICS, isn't it? <1><6dd453>: Abbrev Number: 63 (DW_TAG_subprogram) DW_AT_sibling : <6dd4b5> DW_AT_name : (indirect string, offset: 0x38365): real_lookup DW_AT_decl_file : 1 DW_AT_decl_line : 447 DW_AT_prototyped : 1 DW_AT_type : <6d4e44> DW_AT_inline : 1 (inlined) <2><6dd465>: Abbrev Number: 61 (DW_TAG_formal_parameter) DW_AT_name : (indirect string, offset: 0x8bfef): parent DW_AT_decl_file : 1 DW_AT_decl_line : 446 DW_AT_type : <6d4e44> <2><6dd471>: Abbrev Number: 61 (DW_TAG_formal_parameter) DW_AT_name : (indirect string, offset: 0x43b44): name DW_AT_decl_file : 1 DW_AT_decl_line : 446 DW_AT_type : <6d7bc9> <2><6dd47d>: Abbrev Number: 50 (DW_TAG_formal_parameter) DW_AT_name : nd DW_AT_decl_file : 1 DW_AT_decl_line : 446 DW_AT_type : <6d7b2b> <2><6dd488>: Abbrev Number: 51 (DW_TAG_variable) DW_AT_name : (indirect string, offset: 0x38552): result DW_AT_decl_file : 1 DW_AT_decl_line : 448 DW_AT_type : <6d4e44> <2><6dd494>: Abbrev Number: 64 (DW_TAG_variable) DW_AT_name : dir DW_AT_decl_file : 1 DW_AT_decl_line : 449 DW_AT_type : <6d7851> <2><6dd4a0>: Abbrev Number: 65 (DW_TAG_lexical_block) DW_AT_sibling : <6dd4b3> <3><6dd4a5>: Abbrev Number: 51 (DW_TAG_variable) DW_AT_name : (indirect string, offset: 0x211b): dentry DW_AT_decl_file : 1 DW_AT_decl_line : 468 DW_AT_type : <6d4e44> <3><6dd4b1>: Abbrev Number: 58 (DW_TAG_lexical_block) <2><6dd4b3>: Abbrev Number: 58 (DW_TAG_lexical_block)