> On Sep 30, 2019, at 11:58 AM, Andrii Nakryiko <andriin@xxxxxx> wrote: > > Add few macros simplifying BCC-like multi-level probe reads, while also > emitting CO-RE relocations for each read. > > Signed-off-by: Andrii Nakryiko <andriin@xxxxxx> > --- > tools/lib/bpf/bpf_helpers.h | 151 +++++++++++++++++++++++++++++++++++- > 1 file changed, 147 insertions(+), 4 deletions(-) > > diff --git a/tools/lib/bpf/bpf_helpers.h b/tools/lib/bpf/bpf_helpers.h > index a1d9b97b8e15..51e7b11d53e8 100644 > --- a/tools/lib/bpf/bpf_helpers.h > +++ b/tools/lib/bpf/bpf_helpers.h > @@ -19,6 +19,10 @@ > */ > #define SEC(NAME) __attribute__((section(NAME), used)) > > +#ifndef __always_inline > +#define __always_inline __attribute__((always_inline)) > +#endif > + > /* helper functions called from eBPF programs written in C */ > static void *(*bpf_map_lookup_elem)(void *map, const void *key) = > (void *) BPF_FUNC_map_lookup_elem; > @@ -505,7 +509,7 @@ struct pt_regs; > #endif > > /* > - * BPF_CORE_READ abstracts away bpf_probe_read() call and captures offset > + * bpf_core_read() abstracts away bpf_probe_read() call and captures field > * relocation for source address using __builtin_preserve_access_index() > * built-in, provided by Clang. > * > @@ -520,8 +524,147 @@ struct pt_regs; > * actual field offset, based on target kernel BTF type that matches original > * (local) BTF, used to record relocation. > */ > -#define BPF_CORE_READ(dst, src) \ > - bpf_probe_read((dst), sizeof(*(src)), \ > - __builtin_preserve_access_index(src)) > +#define bpf_core_read(dst, sz, src) \ > + bpf_probe_read(dst, sz, \ > + (const void *)__builtin_preserve_access_index(src)) > + > +/* > + * bpf_core_read_str() is a thin wrapper around bpf_probe_read_str() > + * additionally emitting BPF CO-RE field relocation for specified source > + * argument. > + */ > +#define bpf_core_read_str(dst, sz, src) \ > + bpf_probe_read_str(dst, sz, \ > + (const void *)__builtin_preserve_access_index(src)) > + > +#define ___concat(a, b) a ## b > +#define ___apply(fn, n) ___concat(fn, n) > +#define ___nth(_1, _2, _3, _4, _5, _6, _7, _8, _9, _10, __11, N, ...) N We are adding many marcos with simple names: ___apply(), ___nth. So I worry they may conflict with macro definitions from other libraries. Shall we hide them in .c files or prefix/postfix them with _libbpf or something? Thanks, Song
