Re: Semantic error with demo scripts..

Re: Semantic error with demo scripts..

[Li Guanglei]

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.

Re: Semantic error with demo scripts..

[S. P. Prasanna]

On Fri, Sep 22, 2006 at 02:56:45PM -0700, Stone, Joshua I wrote:
> On Friday, September 22, 2006 2:30 PM, S. P. Prasanna wrote:
> > Hi,
> > 
> > I am getting semantic errors while running scripts from small_demo
> > directory. This happens on default installation on PPC64 RHEL-4 update
> > 4. Also I am not able to use lket as well.
> > Please let me know if you need more details.
> 
> 
[....]
> You could copy tapset/signal.stp into your installed runtime directory,
> or modify your copy of proc_snoop to use the old ones
> (process.signal_send & process.signal_handle).

You are right.

I used the scripts from the CVS build, since I could not find
the example scripts on the defaults Red Hat Enterprise Linux-AS 4,
Update 4 for ppc64. 

It would be helpful if the default installations will have the
"working" demo scripts along with tapsets and runtime.

Should the default RHEL rpms also contain some sample scripts along
with the tapsets and runtime ?


> 
> Or just update your installed systemtap to a CVS build.

The requirement is that, I have to use the default rhel4 installation.
Cant update it.

> 
> > # 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.
> 
> Is this a UP kernel?  Some of the scheduler probes only apply to SMP
> systems, and I've been meaning to clean it up so they don't error on UP
> systems.  I just need a round tuit...
> 

It an PPC64 box with 4 cores. 

> > # ./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")
> 
> You had more success than I did -- when I run this script I get 14 probe
> points not found (on 2.6.9-42.ELsmp i686).  I think the syscall tapset
> still needs some '?'s sprinkled on probe points that aren't universally
> available.

Yes, someone need to work on that.
> 
> > # stap -v -e 'probe addevent.syscall {}' -bM Pass 1: parsed user
> > script and 25 library script(s) in 230usr/0sys/233real ms. 
> > 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 addevent.syscall  
> > Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 global(s) in
> > 0usr/0sys/3real ms. 
> > Pass 2: analysis failed.  Try again with more '-v' (verbose) options.
> 
> Again I think you're the victim of being out-of-date -- LKET might not
> be included in your installed version.  Even if it was, addevent.syscall
> will probably fail in the same way that sys.stp did for you, since they
> both reference 'syscall.*'.

I see some tapsets in LKET directory 
/usr/share/systemtap/tapset/LKET/ with default rhel 4 update-4
installation-ppc64. Did someone checked it?
But none seem to work.. Is LKET supported on RHEL 4 Update4?
If not, it should be documented??


Thanks
Prasanna
-- 
Prasanna S.P.
Linux Technology Center
India Software Labs, IBM Bangalore
Email: prasanna@in.ibm.com
Ph: 91-80-41776329

RE: Semantic error with demo scripts..

[Stone, Joshua I]

On Friday, September 22, 2006 2:30 PM, S. P. Prasanna wrote:
> Hi,
> 
> I am getting semantic errors while running scripts from small_demo
> directory. This happens on default installation on PPC64 RHEL-4 update
> 4. Also I am not able to use lket as well.
> Please let me know if you need more details.

Ok, let's see what's up...

> # ./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.

You are using a test script from CVS with the default systemtap install
(an older version).  The signal tapset is fairly new, so your installed
version probably doesn't have it.

You could copy tapset/signal.stp into your installed runtime directory,
or modify your copy of proc_snoop to use the old ones
(process.signal_send & process.signal_handle).

Or just update your installed systemtap to a CVS build.

> # 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.

Is this a UP kernel?  Some of the scheduler probes only apply to SMP
systems, and I've been meaning to clean it up so they don't error on UP
systems.  I just need a round tuit...

> # ./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")

You had more success than I did -- when I run this script I get 14 probe
points not found (on 2.6.9-42.ELsmp i686).  I think the syscall tapset
still needs some '?'s sprinkled on probe points that aren't universally
available.

> # stap -v -e 'probe addevent.syscall {}' -bM Pass 1: parsed user
> script and 25 library script(s) in 230usr/0sys/233real ms. 
> 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 addevent.syscall  
> Pass 2: analyzed script: 0 probe(s), 0 function(s), 0 global(s) in
> 0usr/0sys/3real ms. 
> Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

Again I think you're the victim of being out-of-date -- LKET might not
be included in your installed version.  Even if it was, addevent.syscall
will probably fail in the same way that sys.stp did for you, since they
both reference 'syscall.*'.


Josh