From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16492 invoked by alias); 24 Oct 2006 17:58:03 -0000 Received: (qmail 16484 invoked by uid 22791); 24 Oct 2006 17:58:02 -0000 X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,BAYES_20,FORGED_RCVD_HELO,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from c-24-5-197-144.hsd1.ca.comcast.net (HELO gateway.sf.frob.com) (24.5.197.144) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 24 Oct 2006 17:57:57 +0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id E4CD3357B; Tue, 24 Oct 2006 10:57:54 -0700 (PDT) Received: by magilla.sf.frob.com (Postfix, from userid 5281) id 95BA7180059; Tue, 24 Oct 2006 10:57:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: "Gui,Jian" Cc: systemtap@sources.redhat.com, "Frank Ch. Eigler" Subject: Re: "no match" semantic error for some existing probe points In-Reply-To: Gui,Jian's message of Thursday, 19 October 2006 15:39:22 +0800 <45372BAA.7000500@cn.ltcfwd.linux.ibm.com> X-Zippy-Says: BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI- Message-Id: <20061024175754.95BA7180059@magilla.sf.frob.com> Date: Tue, 24 Oct 2006 17:58:00 -0000 X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00241.txt.bz2 > Is it a GCC bug? or is it the expected behavior considering GCC's > optimizations? for ptrace_disable() is like: > > 245 void ptrace_disable(struct task_struct *child) > 246 { > 247 /* make sure the single step bit is not set. */ > 248 clear_single_step(child); > 249 } It's likely you are just seeing the result of optimization. If there is no prologue for the function (likely), then there is no code at line 246. clear_single_step is inlined, so there is no code at line 248 except for what's inlined and so resolves to ptrace-common.h or to bitops.h where the clear_tsk_thread_flag inline is defined. In the DWARF line information, each PC is resolved to one source location. For inlines, this means the location of the inline's definition, and not the source location where the inline is called. So using only the line info, you can't help this. There should be a DW_TAG_inlined_subroutine containing this PC range. That should have DW_AT_call_{file,line} attributes that say ptrace.c line 248. If the compiler is producing this info, then we could potentially make systemtap use it. The structure of DWARF information unfortunately does not make this especially easy. Thanks, Roland