[Bug translator/16941] New: fix listing mode inconsistencies

["jlebon at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16941

            Bug ID: 16941
           Summary: fix listing mode inconsistencies
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: jlebon at redhat dot com

On jlebon/listing, I've pushed a testcase which verifies that stap -l for the
great majority of possible probe points are listed as expected and in a
consistent manner.

The test currently checks the listings for 994 different invocations of stap
-l, of which 260 are passing, and 734 are failing. There are likely some false
positives in there, in which the expected string needs to be adjusted. The most
important failures relate to library probes.

I will just go over some of the failures I've looked into so far:

1. kernel.data appends .length(1) in the listing

It could go either way here. The added .length(1) makes it explicit that the
breakpoint is placed on the first byte only. But there are other cases where we
hide these specifications and only display the pp in the same form as what the
user entered, rather than the full derivation (e.g. plt->plt.statement).

executing: stap -l kernel.data(0x123).rw
received: "kernel.data(0x123).length(1).rw"
expected: "kernel.data(0x123).rw"
FAIL: listing_mode (kernel.data(0x123).rw )

executing: stap -l kernel.data(0x123).write
received: "kernel.data(0x123).length(1).write"
expected: "kernel.data(0x123).write"
FAIL: listing_mode (kernel.data(0x123).write )

executing: stap -l kernel.data("abcd").rw
received: "kernel.data("abcd").length(1).rw"
expected: "kernel.data("abcd").rw"
FAIL: listing_mode (kernel.data("abcd").rw )

executing: stap -l kernel.data("abcd").write
received: "kernel.data("abcd").length(1).write"
expected: "kernel.data("abcd").write"
FAIL: listing_mode (kernel.data("abcd").write )

2. kprobe.function(str) vs. kprobe.function(str).call

It seems like kprobe_builder::build() registers the .call variants yet does
nothing with it. What's the difference between kprobe.function(str) and
kprobe.function(str).call? If there is one, then we should also print the
'.call' in the listing. Even if there is none, we might consider including it
in the listing to be more consistent.

executing: stap -l kprobe.function("vfs_read")
received: "kprobe.function("vfs_read")"
expected: "kprobe.function("vfs_read")"
PASS: listing_mode (kprobe.function("vfs_read") )

executing: stap -l kprobe.function("vfs_read").call
received: "kprobe.function("vfs_read")"
expected: "kprobe.function("vfs_read").call"
FAIL: listing_mode (kprobe.function("vfs_read").call )

3. perf probes adds .sample(NUM) in the listings

Again, like 1. above, it could go either way. We can choose to hide the
.sample(NUM) or include it to be more explicit in our derivation.

executing: stap -l perf.type(1).config(1)
received: "perf.type(1).config(1).sample(1000000)"
expected: "perf.type(1).config(1)"
FAIL: listing_mode (perf.type(1).config(1) )

executing: stap -l perf.type(1).config(1).counter("string")
received: "perf.type(1).config(1).sample(0).counter("string")"
expected: "perf.type(1).config(1).counter("string")"
FAIL: listing_mode (perf.type(1).config(1).counter("string") )

executing: stap -l perf.type(1).config(1).process -c ls
received: "perf.type(1).config(1).sample(1000000).process("/usr/bin/ls")"
expected: "perf.type(1).config(1).process"
FAIL: listing_mode (perf.type(1).config(1).process -c ls)

executing: stap -l perf.type(1).config(1).process("string")
received: "perf.type(1).config(1).sample(1000000).process("string")"
expected: "perf.type(1).config(1).process("string")"
FAIL: listing_mode (perf.type(1).config(1).process("string") )

executing: stap -l perf.type(1).config(1).process("string").counter("string")
received:
"perf.type(1).config(1).sample(0).process("string").counter("string")"
expected: "perf.type(1).config(1).process("string").counter("string")"
FAIL: listing_mode (perf.type(1).config(1).process("string").counter("string")
)

4. wildcarded process function probes not set as optional and not complete

When specifying a globby process probe component, the
derived_probe::script_location() heuristics pick the intermediate result in
which the function is not yet fully resolved, and the probe is not set as
optional.

executing: stap -l process("*listing_mode").function("foo")
received:
"process("/home/yyz/jlebon/codebase/systemtap/build/testsuite/listing_mode").function("foo")"
expected:
"^process\("/home/yyz/jlebon/codebase/systemtap/build/testsuite/listing_mode"\)\.function\("foo@[^:]+:23"\)\?$"
FAIL: listing_mode (process("*listing_mode").function("foo") )

The one we ideally would want to list:

$ stap -l 'process("*listing_mode").function("foo")' -vvv
...
          [0]:
process("/home/yyz/jlebon/codebase/systemtap/build/testsuite/listing_mode").function("foo@../../systemtap/testsuite/systemtap.base/listing_mode.c:23")?
...

5. library probes with local shared lib

When specifying a shared library located in the current directory, the focus
switches to that library and listings completely forgo the original -c command
(or the original process("path")):

executing: stap -l process.library("liblisting_mode.so").function(0x798)  -c
listing_mode
received:
"process("/home/yyz/jlebon/codebase/systemtap/build/testsuite/liblisting_mode.so").function(0x798)"
expected:
"process("/home/yyz/jlebon/codebase/systemtap/build/testsuite/listing_mode").library("/home/yyz/jlebon/codebase/systemtap/build/testsuite/liblisting_mode.so").function(0x798)"
FAIL: listing_mode (process.library("liblisting_mode.so").function(0x798)  -c
listing_mode)

executing: stap -l
process("listing_mode").library("liblisting_mode.so").function(0x798)
received:
"process("/home/yyz/jlebon/codebase/systemtap/build/testsuite/liblisting_mode.so").function(0x798)"
expected:
"process("/home/yyz/jlebon/codebase/systemtap/build/testsuite/listing_mode").library("/home/yyz/jlebon/codebase/systemtap/build/testsuite/liblisting_mode.so").function(0x798)"
FAIL: listing_mode
(process("listing_mode").library("liblisting_mode.so").function(0x798) )

6. library probes function(NUM) not printed as hex

executing: stap -l process.library("*liblisting_mode.so").function(0x798)  -c
listing_mode
received:
"process("/home/yyz/jlebon/codebase/systemtap/build/testsuite/listing_mode").library("/home/yyz/jlebon/codebase/systemtap/build/testsuite/liblisting_mode.so").function(1944)?"
expected:
"process("/home/yyz/jlebon/codebase/systemtap/build/testsuite/listing_mode").library("/home/yyz/jlebon/codebase/systemtap/build/testsuite/liblisting_mode.so").function(0x798)?"
FAIL: listing_mode (process.library("*liblisting_mode.so").function(0x798)  -c
listing_mode)

---

There are many more failures, but for now will focus on the above.

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