As it is, pp() from within a process.mark probe returns something like process(..).statement(23748234), whereas the original mark() would be rather more informative appropriate. One problem is that the current rewriting machinery (sdt_query::handle_query_module) creates a synthetic probe that maintains no relationship to the original one. If it created an alias_derived_probe, then at least a aliaswise derivation chain would be preserved. Considering that existing aliases like "syscall.open" result in pp()'s that are the most-expanded, 'kernel.function("...")' strings, we may also need another pp() variant that gives the least-expanded (but including wildcard expansions) probe point -- i.e., the topmost alias name. For this function, say, pp1(), we could return syscall.open and indeed process("...").mark("..."). The future data emitted into the generated C code to enable pp1() could be conditionally compiled in iff pp1() is present in the script code -- kind of like what we do for STP_NEED_SYMBOL_DATA etc.
(In reply to comment #0) > One problem is that the current rewriting machinery > (sdt_query::handle_query_module) creates a synthetic probe that maintains > no relationship to the original one. If it created an alias_derived_probe, > then at least a aliaswise derivation chain would be preserved. I mentioned this issue in bug #10788 comment #1 too. I'm going to file a separate bug to address this.
commit 2d76777 (I'm not sure I like the name pp1(), but no alternative came to mind...)
On Wed, 2010-06-23 at 05:06 +0000, jistone at redhat dot com wrote: ------- Additional Comments From jistone at redhat dot com 2010-06-23 05:06 ------- > commit 2d76777 > > (I'm not sure I like the name pp1(), but no alternative came to mind...) > pp1() is pretty obscure. What about pn() for probe-name (where pp() is for probe-point)? Cheers, Mark
(In reply to comment #3) > pp1() is pretty obscure. Agree. > What about pn() for probe-name (where pp() is for probe-point)? Sound better than "pretty please" or "people", but can be misleading. After all the name of the probe alias is returned here. I suggest following renames: pp() -> ppname() ppl() -> paname() and leaving pp() as (deprecated) alias for new name (backward compatibility or maybe only via --compatible). Yes, new names would be more verbose, but also more clean IMHO. What do you think?
I'm not too keen on verbosifying the function names, nor deprecating one of the most used tapset functions (pp()). One other possibility is to permit and use tapset function overloading: pp()==pp(0) pp1 to become pp(1). This would also be useful for PR11679.
(In reply to comment #3) > What about pn() for probe-name (where pp() is for probe-point)? I like this... commit d48df0c