This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Semantic error with demo scripts..
- From: Li Guanglei <guanglei at cn dot ibm dot com>
- To: prasanna at in dot ibm dot com
- Cc: joshua dot i dot stone at intel dot com, anil dot s dot keshavamurthy at intel dot com, "systemtap at sourceware dot org" <systemtap at sourceware dot org>
- Date: Mon, 25 Sep 2006 17:59:23 +0800
- Subject: Re: Semantic error with demo scripts..
- Organization: IBM CSTL
- References: <20060922213013.GB5677@in.ibm.com>
S. P. Prasanna wrote:
Hi,
# ./proc_snoop.stp
semantic error: probe point mismatch at position 0 (alternatives: _process begin end hrtimer(string) ioblock ioscheduler kernel module(string) netdev never pagefault process scheduler scsi syscall timer)
while: resolving probe point signal.send
semantic error: probe point mismatch at position 0 (alternatives: _process begin end hrtimer(string) ioblock ioscheduler kernel module(string) netdev never pagefault process scheduler scsi syscall timer)
while: resolving probe point signal.handle
Pass 2: analysis failed. Try again with more '-v' (verbose) options.
I tried on my ppc64, it will report:
semantic error: failed to retrieve location attribute for local 'sig'
(dieoffset: 0xad505): identifier '$sig' at
/usr/local/share/systemtap/tapset/signal.stp:377:11
It is because handle_signal is optimized as inline and currently we
can't visit the arguments of inline function due to the absent DWARF
info.
# stap -v -g sched_snoop.stp Pass 1: parsed user script and 25 library script(s) in 230usr/0sys/235real ms.
semantic error: no match for probe point
while: resolving probe point kernel.inline("pull_task")
semantic error: no match for probe point
while: resolving probe point scheduler.migrate
Pass 2: analyzed script: 5 probe(s), 29 function(s), 1 global(s) in 320usr/50sys/365real ms.
Pass 2: analysis failed. Try again with more '-v' (verbose) options.
I failed too on a 4-way ppc64/2.6.17.13/elfutils 0.123. I looked at
the DWARF info of pull_task, but it looks good to me. Didn't figure
out why it failed. Here is the DWARF info:
...
<2><332512>: Abbrev Number: 58 (DW_TAG_inlined_subroutine)
DW_AT_sibling : <33254c>
DW_AT_abstract_origin: <332621>
DW_AT_ranges : 88224
DW_AT_call_file : 0
DW_AT_call_line : 0
<3><332521>: Abbrev Number: 71 (DW_TAG_formal_parameter)
DW_AT_abstract_origin: <33262f>
<3><332526>: Abbrev Number: 59 (DW_TAG_formal_parameter)
DW_AT_abstract_origin: <33263b>
DW_AT_location : 446571 (location list)
....
<1><332621>: Abbrev Number: 87 (DW_TAG_subprogram)
DW_AT_sibling : <332676>
DW_AT_name : (indirect string, offset: 0x168bf): pull_task
DW_AT_decl_file : 1
DW_AT_decl_line : 1802
DW_AT_prototyped : 1
DW_AT_inline : 1 (inlined)
<2><33262f>: Abbrev Number: 86 (DW_TAG_formal_parameter)
DW_AT_name : (indirect string, offset: 0x16dab): src_rq
DW_AT_decl_file : 1
DW_AT_decl_line : 1800
DW_AT_type : <32fe63>
<2><33263b>: Abbrev Number: 86 (DW_TAG_formal_parameter)
...
# ./sys.stp
semantic error: no match for probe point
while: resolving probe point kernel.function("sys_chown16")
semantic error: no match for probe point
while: resolving probe point kernel.function("sys_fchown16")
semantic error: no match for probe point
while: resolving probe point kernel.function("sys_getgid16")
It works fine for me. I looked at the latest codes in CVS, and found
these probes are already optional.