amacleod and others have occasionally asked for the ability for a script to refer to $vars that may not actually exist at the given probe point for whatever reason. The idea would be to let the translator accept such scripts, substituting a literal '0' and I guess a warning at translate time. One possibility is to just make this a session-level flag driven by a new command line argument. The effect would be to change tapsets.cxx:4634ish (the catch semantic-error block in dwrf_var_expanding_copy_visitor) ... or perhaps translate.cxx's c_unparser::visit_target_symbol to behave differently if this flag is set. (Other $var sources like markers might need this sort of treatment too.) Another possibility is to let individual variables/expressions be marked with ?, as in $?var, but that might require more guesswork from the user than should be expected of her.
Such a functionality would help address name-space issues that might arise due to distinct variable names based on CONFIG_<>. Using a combination of '?' for function names and say $?var on variables, differences in kernel code based on CONFIG_<> option can be tolerated by the tapset/script.
Created attachment 3808 [details] patch for review substitutes target symbol with literal 0 on enabling session level flag via --ignore-context
I'd rename "--ignore-context" to "--skip-badvars" or somesuch and maybe tighten up the warning message, but otherwise looks great. A blurb in NEWS/stap.1.in and a test case would complete the job.
commit 3bd0d4d