[Bug translator/11424] New: 'kprobe.function("foo") !' doesn't work like 'kernel.function("foo") !'

[Bug translator/11424] New: 'kprobe.function("foo") !' doesn't work like 'kernel.function("foo") !'

[dsmith at redhat dot com]

Observe the following:

# stap -e 'probe kernel.function("foo") !, kernel.function("sys_read")
{printf("read\n"); exit()}'
read
# stap -e 'probe kernel.function("foo") ?, kernel.function("sys_read")
{printf("read\n"); exit()}'
read

Since function "foo" doesn't exist, '!' (optional and sufficient) and '?'
(optional) act exactly the same.

However:

# stap -e 'probe kprobe.function("foo") ?, kprobe.function("sys_read")
{printf("read\n"); exit()}'
read
# stap -e 'probe kprobe.function("foo") !, kprobe.function("sys_read")
{printf("read\n"); exit()}'
<ctrl-C>

In this last case, '!' seems to mark "foo" as sufficient, even if it doesn't exist.

-- 
           Summary: 'kprobe.function("foo") !'  doesn't work like
                    'kernel.function("foo") !'
           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=11424

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

[Bug translator/11424] dwarfless kprobe.* probes don't validate at translate time

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-03-23 21:15 -------
This is because kprobe.* probes cannot currently be tested
for validity at translate time.  If the logic looked through
a symbol table of some sort, it could work.  It could then
expand wildcards.

session.exported_symbols is actually a plausible source of
such data, even though it's only a subset.  $kernel-builddir/System.map
is another plausible source.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|'kprobe.function("foo") !'  |dwarfless kprobe.* probes
                   |doesn't work like           |don't validate at translate
                   |'kernel.function("foo") !'  |time


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

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

[Bug translator/11424] dwarfless kprobe.* probes don't validate at translate time

[dsmith at redhat dot com]

------- Additional Comments From dsmith at redhat dot com  2010-03-23 22:00 -------
(In reply to comment #1)
> This is because kprobe.* probes cannot currently be tested
> for validity at translate time.

One (not necessarily great) possibility would be to test for validity at run-time.

>  If the logic looked through
> a symbol table of some sort, it could work.  It could then
> expand wildcards.
> 
> session.exported_symbols is actually a plausible source of
> such data, even though it's only a subset.  $kernel-builddir/System.map
> is another plausible source.

If we can't get this working, another possibility here would be to disallow '!'
for kprobe.function.  This would be better than not working as advertised.

-- 


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

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

[Bug translator/11424] dwarfless kprobe.* probes don't validate at translate time

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-03-23 22:22 -------
(In reply to comment #2)
> If we can't get this working, another possibility here would be to disallow '!'
> for kprobe.function.  This would be better than not working as advertised.

This goes a little farther than that.  We have many other probe types
that can silently fail to register at pass-5 time, and not participate
"!" cuts.  timer.profile, perf.*, some kprobe/uprobe related ones, ...
Emulating the full logic of ! etc. at run time could be pretty complicated.


-- 


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

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

[Bug translator/11424] dwarfless kprobe.* probes don't validate at translate time

[prerna at linux dot vnet dot ibm dot com]

------- Additional Comments From prerna at linux dot vnet dot ibm dot com  2010-03-24 09:51 -------
(In reply to comment #1)
> This is because kprobe.* probes cannot currently be tested
> for validity at translate time.  

Brings me to a related issue. A stap -l listing holds no meaning for certain
probe types whose validation can happen only at runtime (eg Dwarfless probes ,
hardware breakpoint probes). Ideally,
$ stap -l ' kprobe.function("sys_*")'
should flag an error. But it returns the same probe point:
$ stap -l ' kprobe.function("sys_*")'
kprobe.function("sys_*")
$

The -l listing needs to be restricted only to certain probe types ; and disabled
for others.

-- 


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

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

[Bug translator/11424] dwarfless kprobe.* probes don't validate at translate time

[prerna at linux dot vnet dot ibm dot com]

------- Additional Comments From prerna at linux dot vnet dot ibm dot com  2010-03-24 10:44 -------
(In reply to comment #4)
> Brings me to a related issue. A stap -l listing holds no meaning for certain
> probe types whose validation can happen only at runtime (eg Dwarfless probes ,
> hardware breakpoint probes). 

Here's a quick patch to prohibit listing mode for dwarfless and hardware
breakpoint based probes.

Index: systemtap/tapsets.cxx
===================================================================
--- systemtap.orig/tapsets.cxx
+++ systemtap/tapsets.cxx
@@ -5452,6 +5452,9 @@ kprobe_builder::build(systemtap_session 
   bool has_function_str, has_module_str, has_statement_num;
   bool has_absolute, has_return, has_maxactive;
 
+  if ( sess.listing_mode || sess.listing_mode_vars )
+	throw semantic_error("Dwarfless probes get validated at runtime. A listing is
not available");
+
   has_function_str = get_param(parameters, TOK_FUNCTION, function_string_val);
   has_module_str = get_param(parameters, TOK_MODULE, module_string_val);
   has_return = has_null_param (parameters, TOK_RETURN);
@@ -5789,6 +5792,9 @@ hwbkpt_builder::build(systemtap_session 
   int64_t hwbkpt_address, len;
   bool has_addr, has_symbol_str, has_write, has_rw, has_len;
 
+  if ( sess.listing_mode || sess.listing_mode_vars )
+	throw semantic_error("Hardware breakpoint probes get validated at runtime. A
listing is not available");
+
   if (! (sess.kernel_config["CONFIG_PERF_EVENTS"] == string("y")))
       throw semantic_error ("CONFIG_PERF_EVENTS not available on this kernel",
                             location->components[0]->tok);

-- 


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

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

[Bug translator/11424] dwarfless kprobe.* probes don't validate at translate time

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2010-03-24 11:04 -------
The fact that probes resolve, but might not trigger/register at runtime since
they aren't available then isn't really an error, even in -l/-L mode IMHO.

It would be nicer to give a WARNING that the probe syntax itself is valid, but
might not trigger or register at runtime.

-- 


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

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

[Bug translator/11424] dwarfless kprobe.* probes don't validate at translate time

[prerna at linux dot vnet dot ibm dot com]

------- Additional Comments From prerna at linux dot vnet dot ibm dot com  2010-03-24 18:28 -------
(In reply to comment #6)
> The fact that probes resolve, but might not trigger/register at runtime since
> they aren't available then isn't really an error, even in -l/-L mode IMHO.
> It would be nicer to give a WARNING that the probe syntax itself is valid, but
> might not trigger or register at runtime.

Probe syntax gets validated at pass 1 anyway :-)

If by probe resolution you mean finding addresses for a supplied symbol argument
in the script, this happens only at runtime. In other words, a dwarfless /
hardware breakpoint probe gets registered only if the address for supplied name
can be decoded, and required resources are available.

IMHO the purpose of -l/-L modes is to list all probes with argument symbols
matching a given pattern -- which is really not possible to find out at
translation stage for such cases. This is why it appears moot for such probe
families.

-- 


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

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

[Bug translator/11424] dwarfless kprobe.* probes don't validate at translate time

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-03-24 18:33 -------
> If by probe resolution you mean finding addresses for a supplied symbol argument
> in the script, this happens only at runtime.

Yes, except that we could *still* do some of this at translate time based on
System.map.  Perhaps as a heuristic only for wildcard expansion and warning
generation.

-- 


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

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