Thread (47 messages) 47 messages, 9 authors, 2019-10-02

Re: [PATCH bpf-next 4/6] libbpf: add BPF_CORE_READ/BPF_CORE_READ_INTO helpers

From: Song Liu <hidden>
Date: 2019-10-01 21:14:36
Also in: bpf

quoted hunk ↗ jump to hunk
On Sep 30, 2019, at 11:58 AM, Andrii Nakryiko [off-list ref] 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 <redacted>
---
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help