[Bug translator/10568] New: translator issue with tapsets

[Bug translator/10568] New: translator issue with tapsets

[dsmith at redhat dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4800 bytes --]

According to the stap man page, when describing pass 2, it says the following:

       References to variables, functions, and probe aliases  that
       are unresolved internally are satisfied by searching through the parsed
       tapset scripts.  If any tapset script is selected because it defines an
       unresolved  symbol,  then  the  entirety of that script is added to the
       translator’s resolution queue.

The "entirety of that script" may be "added to the translator's resolution
queue", but the translator seems to throw away portions of the tapset script,
even in unoptimized mode.  Here are some examples:

(1) test 1 setup:

== test/test.stp ==
probe tapset_test.foo { }
====

== test/t1/tapset_test.stp ==
global _reads

probe tapset_test.foo = never { }

probe kernel.function("sys_read") { _reads++ }

probe timer.s(5) { printf("%d\n", _reads) }
====

# stap -p2 -v -I t1 test.stp
Pass 1: parsed user script and 60 library script(s) in 160usr/30sys/190real ms.
WARNING: side-effect-free probe 'probe_1809': identifier 'tapset_test' at
test.stp:1:7
 source: probe tapset_test.foo { }
               ^
# probes
never /* <- tapset_test.foo = never <- tapset_test.foo */
;
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s) in
0usr/0sys/13real ms.

Even though the tapset_test.stp tapset file was included (to satisfy the
'tapset_test.foo' reference), the other probes in that file were not included in
the pass 2 output.

Note that turning off the optimizer causes the 'side-effect-free probe' warning
to go away, but still the other probes in that file are not included.

# stap -u -p2 -v -I t1 test.stp
Pass 1: parsed user script and 60 library script(s) in 130usr/40sys/176real ms.
# probes
never /* <- tapset_test.foo = never <- tapset_test.foo */
{
{
}
{
}
}
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s) in
10usr/0sys/10real ms.

The translator is discarding the kernel.function() probe and the timer probe.
Note that you can substitute a 'begin' probe for the 'never' probe in
tapset_test.stp and see the same problem.

Note that you can workaround this particular problem (in both optimized and
unoptimized form) by adding a dummy reference to '_reads' in the
'tapset_test.foo' probe.

== test/t1/tapset_test.stp ==
global _reads

probe tapset_test.foo = never { _reads = 0 }

probe kernel.function("sys_read") { _reads++ }

probe timer.s(5) { printf("%d\n", _reads) }
====

# stap -p2 -v -I t1 test.stp
Pass 1: parsed user script and 60 library script(s) in 140usr/40sys/177real ms.
# globals
_reads:long
# probes
never /* <- tapset_test.foo = never <- tapset_test.foo */
(_reads) = (0)
kernel.function("sys_read@fs/read_write.c:372") /* pc=_stext+0xccbb6 */ /* <-
kernel.function("sys_read") */
(_reads)++
timer.s(5) /* <- timer.s(5) */
printf("%d\\n", _reads)
Pass 2: analyzed script: 3 probe(s), 0 function(s), 0 embed(s), 1 global(s) in
380usr/40sys/429real ms.

(2) test 2 setup:

== test/test.stp ==
probe tapset_test.foo { }
====

This file is unchanged.

== test/t2/tapset_test.stp ==
probe tapset_test.foo = never { _reads = 0 }

probe kernel.function("sys_read") { _reads++ }

probe timer.s(5) { printf("%d\n", _reads) }
====

== test/t2/vars.stp ==
global _reads
====

I've moved the 'global _vars' statement from tapset_test.stp to tapset_vars.stp.
 Notice I'm using the workaround mentioned in (1) of a dummy reference to
'_reads' in the tapset_test.foo probe.

# stap -p2 -v -I t2 test.stp
Pass 1: parsed user script and 61 library script(s) in 150usr/30sys/183real ms.
# globals
_reads:long
# probes
never /* <- tapset_test.foo = never <- tapset_test.foo */
(_reads) = (0)
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 1 global(s) in
10usr/0sys/7real ms.

# stap -u -p2 -v -I t2 test.stp
Pass 1: parsed user script and 61 library script(s) in 130usr/40sys/169real ms.
# globals
_reads:long
# probes
never /* <- tapset_test.foo = never <- tapset_test.foo */
{
{
(_reads) = (0)
}
{
}
}
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 1 global(s) in
0usr/0sys/9real ms.

Once again, in both optimized and unoptimized modes, the translator is
discarding the kernel.function() probe and the timer probes.

I have not found a workaround for this variant of the problem.

-- 
           Summary: translator issue with tapsets
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: dsmith at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=10568

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10568] translator issue with tapsets

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-08-27 18:39 -------
(In reply to comment #0)
> WARNING: side-effect-free probe 'probe_1809': identifier 'tapset_test' at
> test.stp:1:7
>  source: probe tapset_test.foo { }
>                ^

Using "next" is probably a good filler to make "never" probes be quiet about
being empty.  It might be good to make never probes silently hide though.

As for the rest -- when we resolve a global or function, we add that file to the
session's active files.  The same needs to be done for aliases.  Please see if
the following works for you:

diff --git a/elaborate.cxx b/elaborate.cxx
index bf57f88..17f335d 100644
--- a/elaborate.cxx
+++ b/elaborate.cxx
@@ -540,7 +540,18 @@ alias_expansion_builder
     else
       n->body = new block (alias->body, use->body);
 
+    unsigned old_num_results = finished_results.size();
     derive_probes (sess, n, finished_results, location->optional);
+
+    // Check whether we resolved something. If so, put the
+    // whole library into the queue if not already there.
+    if (finished_results.size() > old_num_results)
+      {
+        stapfile *f = alias->tok->location.file;
+        if (find (sess.files.begin(), sess.files.end(), f)
+            == sess.files.end())
+          sess.files.push_back (f);
+      }
   }
 
   bool checkForRecursiveExpansion (probe *use)


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10568

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10568] translator issue with tapsets

[dsmith at redhat dot com]

------- Additional Comments From dsmith at redhat dot com  2009-08-27 21:43 -------
That change seems to fix things for me.  Please check it in.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10568

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10568] translator issue with tapsets

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-08-27 22:51 -------
commit a3b4f52cd67ff11dfc12e8e878744ea1319308ef

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=10568

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10568] translator issue with tapsets

[dsmith at redhat dot com]

------- Additional Comments From dsmith at redhat dot com  2009-08-28 19:01 -------
I've added a testcase, called systemtap.base/alias_tapset.exp, for this bug.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10568

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/10568] translator issue with tapsets

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-08-28 19:32 -------
(In reply to comment #4)
> I've added a testcase, called systemtap.base/alias_tapset.exp, for this bug.

My commit also included a testcase, but it looks like we took different
approaches, so they're probably both good to have.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10568

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.