[Bug translator/2422] New: running multiple systemtap instrumentation when module("*") is used

[Bug translator/2422] New: running multiple systemtap instrumentation when module("*") is used

[wcohen at redhat dot com]

If an existing systemtap probe is running, it has a module stap_[0-9]+ installed
in the kernel. When a second systemtap instrumentation probe is attempted the
translator cannot find debuginformation for the stap_[0-9]+ module. So for
example  the tests/testsuite/systemtap.stress/current.stp script was built and
left running (any systemtap instrumentation script would work). A second
current.stp script was attempted and failed in the following way:

$  stap -g  systemtap.stress/current.stp
semantic error: c$  stap -g  systemtap.stress/current.stp
semantic error: cannot find module stap_21942 debuginfo: No such file or directory
semantic error: cannot find module stap_21942 debuginfo: No such file or directory
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.
annot find module stap_21942 debuginfo: No such file or directory
semantic error: cannot find module stap_21942 debuginfo: No such file or directory
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.


This is also going to present a problem for any module that doesn't have
debugging information, e.g. third party device drivers. Shouldn't this be a
warning and just not instrument the module missing the debuginfo rather than
failing?

-- 
           Summary: running multiple systemtap instrumentation when
                    module("*") is used
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: wcohen at redhat dot com


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

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

[Bug translator/2422] module("*") probes fail with debug-info-less modules

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-03-06 16:44 -------
This issue was raised in bug #1931 but not then corrected.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|running multiple systemtap  |module("*") probes fail with
                   |instrumentation when        |debug-info-less modules
                   |module("*") is used         |


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

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

[Bug translator/2422] module("*") probes fail with debug-info-less modules

[guanglei at cn dot ibm dot com]

------- Additional Comments From guanglei at cn dot ibm dot com  2006-07-24 03:37 -------
(In reply to comment #0)
> [..]

Here is a patch. Please take a review. This patch will cause stap to skip a
module without debuginfo only when the probe looks like "probe module("*").xx" 

RCS file: /cvs/systemtap/src/tapsets.cxx,v
retrieving revision 1.137
diff -r1.137 tapsets.cxx
585c585,588
<     get_module_dwarf(true);
---
>     if(module_name != "" && pattern == "*")
>           get_module_dwarf(false);
>     else
>           get_module_dwarf(true);

-- 


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

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

[Bug translator/2422] module("*") probes fail with debug-info-less modules

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-07-24 20:14 -------
What happens if we just switch to get_module_dwarf(false) altogether?  (Testing
for equality with "*" would be insufficient - we have wildcards like "*foo*".)

-- 


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

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

[Bug translator/2422] module("*") probes fail with debug-info-less modules

[guanglei at cn dot ibm dot com]

------- Additional Comments From guanglei at cn dot ibm dot com  2006-07-31 14:32 -------
(In reply to comment #3)
> What happens if we just switch to get_module_dwarf(false) altogether?  (Testing
> for equality with "*" would be insufficient - we have wildcards like "*foo*".)

Simply calling get_module_dwarf(false) seems enough. Here is a patch:

RCS file: /cvs/systemtap/src/tapsets.cxx,v
retrieving revision 1.137
diff -r1.137 tapsets.cxx
558c558
<   void get_module_dwarf(bool required = true)
---
>   void get_module_dwarf(bool required = false)
585c585
<     get_module_dwarf(true);
---
>     get_module_dwarf(false);

This patch will:

if MPATTERN contains wildcard(*,?,[])
{
    foreach module in MPATTERN
    {
        if this module has no debuginfo
            give a warning and continue
    }
    if all modules have no debuginfo
       && this probe point is not optional
    {
        give an error and stop
    }  else
        give a warning and continue
}  else  {
    if this module has no debuginfo 
      && this probe point is not optional
        give an error and stop
    else
        give a warning and continue
}

I tried different combinations and it passed tests:

probe module("*ath*").function("*dispatch*"), kernel.function("sys_getsid")
probe module("*ath*").function("*dispatch*") ?, kernel.function("sys_getsid")
probe module("ath_[abcp]ci").function("*dispatch*"), kernel.function("sys_getsid")
probe module("ath_[abcp]ci").function("*dispatch*")?, kernel.function("sys_getsid")
probe module("ath_[abcp]ci").statement("0xf89aae29")
probe module("ath_[abcp]ci").statement("0xf89aae29")?
...

-- 


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

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

[Bug translator/2422] module("*") probes fail with debug-info-less modules

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-07-31 14:55 -------
Thanks for the testing.  Please feel free to commit the true->false changes.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sources dot    |guanglei at cn dot ibm dot
                   |redhat dot com              |com
             Status|NEW                         |ASSIGNED


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

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