"no match" semantic error for some existing probe points

[Gui,Jian]

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