On Thu, Dec 26, 2019 at 01:18:55PM -0800, Andrii Nakryiko wrote:
> Streamline BPF_TRACE_x macro by moving out return type and section attribute
> definition out of macro itself. That makes those function look in source code
> similar to other BPF programs. Additionally, simplify its usage by determining
> number of arguments automatically (so just single BPF_TRACE vs a family of
> BPF_TRACE_1, BPF_TRACE_2, etc). Also, allow more natural function argument
> syntax without commas inbetween argument type and name.
>
> Given this helper is useful not only for tracing tp_btf/fenty/fexit programs,
> but could be used for LSM programs and others following the same pattern,
> rename BPF_TRACE macro into more generic BPF_HANDLER. Existing BPF_TRACE_x
> usages in selftests are converted to new BPF_HANDLER macro.
>
> Following the same pattern, define BPF_KPROBE and BPF_KRETPROBE macros for
> nicer usage of kprobe/kretprobe arguments, respectively. BPF_KRETPROBE, adopts
> same convention used by fexit programs, that last defined argument is probed
> function's return result.
>
> Signed-off-by: Andrii Nakryiko <andriin@xxxxxx>
...
> +
> +#define BPF_HANDLER(name, args...) \
> +name(unsigned long long *ctx); \
> +static __always_inline typeof(name(0)) ____##name(args); \
> +typeof(name(0)) name(unsigned long long *ctx) \
> +{ \
> + _Pragma("GCC diagnostic push") \
> + _Pragma("GCC diagnostic ignored \"-Wint-conversion\"") \
> + return ____##name(___bpf_ctx_cast(args)); \
> + _Pragma("GCC diagnostic pop") \
It says "GCC ..", but does it actually work with gcc?
If the answer is no, I think it's still ok, but would be good to document.
Other than the above BPF_HANDLER, BPF_KPROBE, BPF_KRETPROBE distinction make sense.
Please document it. It's not obvious when to use each one.
Also the intent is do let users do s/BPF_KRETPROBE/BPF_HANDLER/ conversion
when they transition from kretprobe to fexit without changing anything else
in the function body and function declaration? That's neat if that can work.
