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.
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.
(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.
(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.
(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.
(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);
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.
(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.
> 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.
(In reply to comment #1) > 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. Thinking about this a bit, System.map would work fine for kprobe.function("foo"), but wouldn't work for kprobe.module("module").function("foo"), since System.map only has kernel symbols. But, using System.map would still work much better than what we have now.
Created attachment 6522 [details] preliminary patch Here's a preliminary patch that parses System.map. This needs a bit of polishing, then the nd_syscalls tapset will also need some work.
Fixed in commit 9fdf787.
*** Bug 6864 has been marked as a duplicate of this bug. ***