If runtime=bpf, then log() etc. should relay to { printf(...) } rather than %{ embedded-c %} that won't work under bpf. Generally review tapset *.stp files to see how many of them can grow a bpf variant easily. The list of lower level "bpf helper" functions is very small (kernel tools/include/uapi/linux/bpf.h), so we may need to approximate or stub out, or let the current error message stay for them.
(Note: depends on PR23407.)
Making some progress (as of commit be31be3ff) but there are a number of glitches to work out, e.g.: - exit() in a probe still causes output to be swallowed (PR23435). - error() weirdly does not print anything. - assert() with a nested call to error() causes an invalid eBPF program to be generated.
Some problems in the previous message have been resolved: - error() seems to work now - assert() seems to work now Subtler (as-yet-unimportant) variations from kernel-module backend are noted in comments in the logging.stp tapset. I am also going through some bpf usage examples such as https://blog.yadutaf.fr/2017/07/28/tracing-a-packet-journey-using-linux-tracepoints-perf-ebpf/ to see what other tapset functions are missing. So far (some of these will get filed as follow-up PRs): - context.stp execname() <- implement with bpf_get_current_comm() - context.stp pid() <- implement with bpf_get_current_pid_tgid() - [u]conversions.stp functions such as kernel_string(), kernel_long() <- implement with bpf_probe_read(), bpf_probe_read_str() -- see PR23474 - some oddities with @cast and $variables - kernel-mode backend @cast($skb, "sk_buff")->dev->name currently not working on BPF To implement these functions without having to write a lot of low-level BPF assembly, it may be worth implementing a feature to call eBPF helpers directly from SystemTap code. Perhaps a special syntax such as @bpf_helper(bpf_get_current_comm, ...) would make sense to add for this.
Sounds like it's best to create a tapset bpf/helpers.stp which implements an inline-assembly wrapper for each of the (needed) eBPF helper functions in a way that can be called from other, more friendly tapset functions. Creating new syntax can thus be avoided.
Closing as the log() functions are now working; may return and fix slight behaviour divergences from standard SystemTap as newer embedded-code functionality is finished. The various bits of work required for the 'user story' might result in follow-up PRs for new tapset functionality.