Probe aliases defined thusly: probe foo = bar? { } does not do a lot for a script user. It quietly fails when the underlying bar probe point is not present. If the end-user script wishes to allow this, it should be written with the optional markup of its own: probe foo ? { } We should review the tapset and generally get rid of as many of these optional markers (conditional on %( version %) ) as possible.
(In reply to comment #0) > It quietly fails when the underlying bar probe point is not present. That's not true: $ stap -e 'probe foo = bar ? {} probe foo {}' -p2 semantic error: no match while resolving probe point foo Pass 2: analysis failed. Try again with another '--vp 01' option. The optional tag on the alias allows a user to possibly match the probe with a wildcard, but carry on if it doesn't resolve. $ stap -e 'probe bar = foo ? {} probe b* {}' -p2 -u # probes begin /* <- b* */ vs. $ stap -e 'probe bar = foo {} probe b* {}' -p2 -u semantic error: probe point mismatch at position 0 (alternatives: __nfs __scheduler __signal __tcpmib __vm _linuxmib _signal _sunrpc _syscall _vfs bar begin begin(number) end end(number) error error(number) generic ioblock ioblock_trace ioscheduler ioscheduler_trace ipmib irq_handler kernel kprobe kprocess linuxmib module(string) nd_syscall netdev never nfs nfsd perf process process(number) process(string) procfs procfs(string) scheduler scsi signal socket softirq stap staprun sunrpc syscall tcp tcpmib timer tty udp vfs vm workqueue): identifier 'foo' at <input>:1:13 while resolving probe point foo source: probe bar = foo {} probe b* {} ^ Pass 2: analysis failed. Try again with another '--vp 01' option.
This is not clearly worthwhile. OTOH, bug #14297 comment #3 worries rightly about our overmarking of wildcard-processed/synthetic probes with 'optional' flags.