From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19954 invoked by alias); 18 Oct 2006 04:00:44 -0000 Received: (qmail 19939 invoked by uid 22791); 18 Oct 2006 04:00:43 -0000 X-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ausmtp05.au.ibm.com (HELO ausmtp05.au.ibm.com) (202.81.18.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 18 Oct 2006 04:00:39 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp05.au.ibm.com (8.13.8/8.13.6) with ESMTP id k9I42ffH7970958 for ; Wed, 18 Oct 2006 14:02:46 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.250.243]) by sd0208e0.au.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9I43dX1086984 for ; Wed, 18 Oct 2006 14:03:54 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9I3u4A7018679 for ; Wed, 18 Oct 2006 13:56:04 +1000 Received: from [127.0.0.1] ([9.181.133.111]) by d23av02.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k9I3u0IB018462; Wed, 18 Oct 2006 13:56:03 +1000 Message-ID: <4535A6CB.7090604@cn.ltcfwd.linux.ibm.com> Date: Wed, 18 Oct 2006 04:00:00 -0000 From: "Gui,Jian" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: systemtap@sources.redhat.com Subject: Re: "no match" semantic error for some existing probe points References: <4534AD25.1050205@cn.ltcfwd.linux.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00153.txt.bz2 Frank Ch. Eigler wrote: > Something strange is happening here, probably a translator bug. The > "no match for probe point" message occurs if no "derived_probe" > instances get accumulated for a particular probe construct in the > script. But it should have been created. Debugging this may require > probing the messiest part of the translator: tapsets.cxx, starting > at(say) query_cu. > > - FChE > Thanks. I debugged the translation and found the first error comes from the dwflpp::die_has_pc(die, pc) call in query_srcfile_line(). In the ptrace_disable case, a wrong pc address causes this failure: dwflpp::die_has_pc (this=0x106fcdf8, die=0x10d00c94, pc=0xc000000000009e10) But "objdump -D /boot/vmlinux-2.6.18" shows 0xc000000000009e10 is out of range: c000000000009db0 <.ptrace_disable>: c000000000009db0: e9 23 03 00 ld r9,768(r3) c000000000009db4: 39 60 02 00 li r11,512 c000000000009db8: 2f a9 00 00 cmpdi cr7,r9,0 c000000000009dbc: 41 9e 00 14 beq- cr7,c000000000009dd0 <.ptrace_disable+0x20> c000000000009dc0: e8 09 01 08 ld r0,264(r9) c000000000009dc4: 78 00 a8 42 rldicl r0,r0,53,1 c000000000009dc8: 78 00 58 00 rotldi r0,r0,11 c000000000009dcc: f8 09 01 08 std r0,264(r9) c000000000009dd0: e9 23 00 08 ld r9,8(r3) c000000000009dd4: 38 09 00 80 addi r0,r9,128 c000000000009dd8: 7d 40 00 a8 ldarx r10,0,r0 c000000000009ddc: 7d 4a 58 78 andc r10,r10,r11 c000000000009de0: 7d 40 01 ad stdcx. r10,0,r0 c000000000009de4: 40 a2 ff f4 bne- c000000000009dd8 <.ptrace_disable+0x28> c000000000009de8: 4e 80 00 20 blr I am still looking at how the wrong pc address is generated. btw: I am using elfutils-0.123-0.1 /gcc 3.4.6 20060404 /systemtap-20061017 /RHEL4U3 /2.6.18 /ppc64 -Guijian