* [Buildroot] [PATCH] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-13 21:30 Shahab Vahedi via buildroot
2022-06-14 8:26 ` Shahab Vahedi
2022-06-15 10:57 ` Shahab Vahedi
0 siblings, 2 replies; 43+ messages in thread
From: Shahab Vahedi via buildroot @ 2022-06-13 21:30 UTC (permalink / raw)
To: buildroot
Building bpftool on Debian 11 (bullseye) with kernel v5.10 fails:
-----------------------------------8<-----------------------------------
$ make
.
.
.
CLANG pid_iter.bpf.o
skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type
'struct bpf_perf_link'
perf_link = container_of(link, struct bpf_perf_link, link);
.
.
.
skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in
'struct perf_event'
return BPF_CORE_READ(event, bpf_cookie);
.
.
.
10 errors generated.
make: *** [Makefile:176: pid_iter.bpf.o] Error 1
----------------------------------->8-----------------------------------
There are changes in bpftool v6.8.0 that assumes the existence of
particular data structures in generated vmlinux.h that is obtained
from the host machine. See [1] for further details. This commit adds
a patch to revert that additional change in v6.8.0.
There's a patch series pending to be submitted upstream [2]. Hopefully,
those will take care of the problem if they land in the next release.
[1]
https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
[2]
https://lore.kernel.org/bpf/20220421003152.339542-1-alobakin@pm.me/
Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
---
.../0002-revert-bpf_cookie-change.patch | 114 ++++++++++++++++++
1 file changed, 114 insertions(+)
create mode 100644 package/bpftool/0002-revert-bpf_cookie-change.patch
diff --git a/package/bpftool/0002-revert-bpf_cookie-change.patch b/package/bpftool/0002-revert-bpf_cookie-change.patch
new file mode 100644
index 0000000000..8c9c6d84b1
--- /dev/null
+++ b/package/bpftool/0002-revert-bpf_cookie-change.patch
@@ -0,0 +1,114 @@
+Revert commit "bpftool: Add bpf_cookie to link output"
+
+Building bpftool on Debian bullseye fails [1]. This patch
+reverts the offending commit [2].
+
+[1] Building release 6.8.0 on Debian 11
+https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
+
+[2] bpftool: Add bpf_cookie to link output
+https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=cbdaf71f
+
+Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
+diff --git a/src/main.h b/src/main.h
+index aa99ffa..2f2b638 100644
+--- a/src/main.h
++++ b/src/main.h
+@@ -111,9 +111,7 @@ struct obj_ref {
+
+ struct obj_refs {
+ int ref_cnt;
+- bool has_bpf_cookie;
+ struct obj_ref *refs;
+- __u64 bpf_cookie;
+ };
+
+ struct btf;
+diff --git a/src/pids.c b/src/pids.c
+index e2d00d3..57f0d1b 100644
+--- a/src/pids.c
++++ b/src/pids.c
+@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
+ ref->pid = e->pid;
+ memcpy(ref->comm, e->comm, sizeof(ref->comm));
+ refs->ref_cnt = 1;
+- refs->has_bpf_cookie = e->has_bpf_cookie;
+- refs->bpf_cookie = e->bpf_cookie;
+
+ err = hashmap__append(map, u32_as_hash_field(e->id), refs);
+ if (err)
+@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
+-
+ jsonw_name(json_writer, "pids");
+ jsonw_start_array(json_writer);
+ for (i = 0; i < refs->ref_cnt; i++) {
+@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
+-
+ printf("%s", prefix);
+ for (i = 0; i < refs->ref_cnt; i++) {
+ struct obj_ref *ref = &refs->refs[i];
+diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
+index eb05ea5..f70702f 100644
+--- a/src/skeleton/pid_iter.bpf.c
++++ b/src/skeleton/pid_iter.bpf.c
+@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
+ }
+ }
+
+-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
+-static __u64 get_bpf_cookie(struct bpf_link *link)
+-{
+- struct bpf_perf_link *perf_link;
+- struct perf_event *event;
+-
+- perf_link = container_of(link, struct bpf_perf_link, link);
+- event = BPF_CORE_READ(perf_link, perf_file, private_data);
+- return BPF_CORE_READ(event, bpf_cookie);
+-}
+-
+ SEC("iter/task_file")
+ int iter(struct bpf_iter__task_file *ctx)
+ {
+@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
+ if (file->f_op != fops)
+ return 0;
+
+- __builtin_memset(&e, 0, sizeof(e));
+ e.pid = task->tgid;
+ e.id = get_obj_id(file->private_data, obj_type);
+-
+- if (obj_type == BPF_OBJ_LINK) {
+- struct bpf_link *link = (struct bpf_link *) file->private_data;
+-
+- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
+- e.has_bpf_cookie = true;
+- e.bpf_cookie = get_bpf_cookie(link);
+- }
+- }
+-
+ bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
+ task->group_leader->comm);
+ bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
+diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
+index bbb570d..5692cf2 100644
+--- a/src/skeleton/pid_iter.h
++++ b/src/skeleton/pid_iter.h
+@@ -6,8 +6,6 @@
+ struct pid_iter_entry {
+ __u32 id;
+ int pid;
+- __u64 bpf_cookie;
+- bool has_bpf_cookie;
+ char comm[16];
+ };
+
--
2.30.2
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Buildroot] [PATCH v2 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-13 21:30 [Buildroot] [PATCH] package/bpftool: revert bpf_cookie patch to allow building Shahab Vahedi via buildroot
@ 2022-06-14 8:26 ` Shahab Vahedi
2022-06-15 10:57 ` Shahab Vahedi
1 sibling, 0 replies; 43+ messages in thread
From: Shahab Vahedi via buildroot @ 2022-06-14 8:26 UTC (permalink / raw)
To: buildroot; +Cc: linux-snps-arc
Building bpftool on Debian 11 (bullseye) with kernel v5.10 fails:
-----------------------------------8<-----------------------------------
$ make
.
.
.
CLANG pid_iter.bpf.o
skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type
'struct bpf_perf_link'
perf_link = container_of(link, struct bpf_perf_link, link);
.
.
.
skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in
'struct perf_event'
return BPF_CORE_READ(event, bpf_cookie);
.
.
.
10 errors generated.
make: *** [Makefile:176: pid_iter.bpf.o] Error 1
----------------------------------->8-----------------------------------
There are changes in bpftool v6.8.0 that assumes the existence of
particular data structures in generated vmlinux.h that is obtained
from the host machine. See [1] for further details. This commit adds
a patch to revert that additional change in v6.8.0.
There's a patch series pending to be submitted upstream [2]. Hopefully,
those will take care of the problem if they land in the next release.
Changelog:
v1: Initial submission [3]
v2: Use a full fledged git patch for bpftool
[1]
https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
[2]
https://lore.kernel.org/bpf/20220421003152.339542-1-alobakin@pm.me/
[3]
https://lists.buildroot.org/pipermail/buildroot/2022-June/644819.html
Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
---
.../0002-revert-bpf_cookie-change.patch | 227 ++++++++++++++++++
1 file changed, 227 insertions(+)
create mode 100644 package/bpftool/0002-revert-bpf_cookie-change.patch
diff --git a/package/bpftool/0002-revert-bpf_cookie-change.patch b/package/bpftool/0002-revert-bpf_cookie-change.patch
new file mode 100644
index 0000000000..cb9ebdec41
--- /dev/null
+++ b/package/bpftool/0002-revert-bpf_cookie-change.patch
@@ -0,0 +1,227 @@
+From: Shahab Vahedi <shahab@synopsys.com>
+Date: Tue, 14 Jun 2022 10:12:21 +0200
+Subject: [PATCH] Revert commit "bpftool: Add bpf_cookie to link output"
+
+Building bpftool on Debian bullseye fails [1]. This patch
+reverts the offending commit [2].
+
+[1] Building release 6.8.0 on Debian 11
+https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
+
+[2] bpftool: Add bpf_cookie to link output
+https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=cbdaf71f
+
+Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
+diff --git a/src/main.h b/src/main.h
+index aa99ffa..2f2b638 100644
+--- a/src/main.h
++++ b/src/main.h
+@@ -111,9 +111,7 @@ struct obj_ref {
+
+ struct obj_refs {
+ int ref_cnt;
+- bool has_bpf_cookie;
+ struct obj_ref *refs;
+- __u64 bpf_cookie;
+ };
+
+ struct btf;
+diff --git a/src/pids.c b/src/pids.c
+index e2d00d3..57f0d1b 100644
+--- a/src/pids.c
++++ b/src/pids.c
+@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
+ ref->pid = e->pid;
+ memcpy(ref->comm, e->comm, sizeof(ref->comm));
+ refs->ref_cnt = 1;
+- refs->has_bpf_cookie = e->has_bpf_cookie;
+- refs->bpf_cookie = e->bpf_cookie;
+
+ err = hashmap__append(map, u32_as_hash_field(e->id), refs);
+ if (err)
+@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
+-
+ jsonw_name(json_writer, "pids");
+ jsonw_start_array(json_writer);
+ for (i = 0; i < refs->ref_cnt; i++) {
+@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
+-
+ printf("%s", prefix);
+ for (i = 0; i < refs->ref_cnt; i++) {
+ struct obj_ref *ref = &refs->refs[i];
+diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
+index eb05ea5..f70702f 100644
+--- a/src/skeleton/pid_iter.bpf.c
++++ b/src/skeleton/pid_iter.bpf.c
+@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
+ }
+ }
+
+-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
+-static __u64 get_bpf_cookie(struct bpf_link *link)
+-{
+- struct bpf_perf_link *perf_link;
+- struct perf_event *event;
+-
+- perf_link = container_of(link, struct bpf_perf_link, link);
+- event = BPF_CORE_READ(perf_link, perf_file, private_data);
+- return BPF_CORE_READ(event, bpf_cookie);
+-}
+-
+ SEC("iter/task_file")
+ int iter(struct bpf_iter__task_file *ctx)
+ {
+@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
+ if (file->f_op != fops)
+ return 0;
+
+- __builtin_memset(&e, 0, sizeof(e));
+ e.pid = task->tgid;
+ e.id = get_obj_id(file->private_data, obj_type);
+-
+- if (obj_type == BPF_OBJ_LINK) {
+- struct bpf_link *link = (struct bpf_link *) file->private_data;
+-
+- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
+- e.has_bpf_cookie = true;
+- e.bpf_cookie = get_bpf_cookie(link);
+- }
+- }
+-
+ bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
+ task->group_leader->comm);
+ bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
+diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
+index bbb570d..5692cf2 100644
+--- a/src/skeleton/pid_iter.h
++++ b/src/skeleton/pid_iter.h
+@@ -6,8 +6,6 @@
+ struct pid_iter_entry {
+ __u32 id;
+ int pid;
+- __u64 bpf_cookie;
+- bool has_bpf_cookie;
+ char comm[16];
+ };
+---
+ src/main.h | 2 --
+ src/pids.c | 8 --------
+ src/skeleton/pid_iter.bpf.c | 22 ----------------------
+ src/skeleton/pid_iter.h | 2 --
+ 4 files changed, 34 deletions(-)
+
+diff --git a/src/main.h b/src/main.h
+index aa99ffa..2f2b638 100644
+--- a/src/main.h
++++ b/src/main.h
+@@ -111,9 +111,7 @@ struct obj_ref {
+
+ struct obj_refs {
+ int ref_cnt;
+- bool has_bpf_cookie;
+ struct obj_ref *refs;
+- __u64 bpf_cookie;
+ };
+
+ struct btf;
+diff --git a/src/pids.c b/src/pids.c
+index e2d00d3..57f0d1b 100644
+--- a/src/pids.c
++++ b/src/pids.c
+@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
+ ref->pid = e->pid;
+ memcpy(ref->comm, e->comm, sizeof(ref->comm));
+ refs->ref_cnt = 1;
+- refs->has_bpf_cookie = e->has_bpf_cookie;
+- refs->bpf_cookie = e->bpf_cookie;
+
+ err = hashmap__append(map, u32_as_hash_field(e->id), refs);
+ if (err)
+@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
+-
+ jsonw_name(json_writer, "pids");
+ jsonw_start_array(json_writer);
+ for (i = 0; i < refs->ref_cnt; i++) {
+@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
+-
+ printf("%s", prefix);
+ for (i = 0; i < refs->ref_cnt; i++) {
+ struct obj_ref *ref = &refs->refs[i];
+diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
+index eb05ea5..f70702f 100644
+--- a/src/skeleton/pid_iter.bpf.c
++++ b/src/skeleton/pid_iter.bpf.c
+@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
+ }
+ }
+
+-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
+-static __u64 get_bpf_cookie(struct bpf_link *link)
+-{
+- struct bpf_perf_link *perf_link;
+- struct perf_event *event;
+-
+- perf_link = container_of(link, struct bpf_perf_link, link);
+- event = BPF_CORE_READ(perf_link, perf_file, private_data);
+- return BPF_CORE_READ(event, bpf_cookie);
+-}
+-
+ SEC("iter/task_file")
+ int iter(struct bpf_iter__task_file *ctx)
+ {
+@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
+ if (file->f_op != fops)
+ return 0;
+
+- __builtin_memset(&e, 0, sizeof(e));
+ e.pid = task->tgid;
+ e.id = get_obj_id(file->private_data, obj_type);
+-
+- if (obj_type == BPF_OBJ_LINK) {
+- struct bpf_link *link = (struct bpf_link *) file->private_data;
+-
+- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
+- e.has_bpf_cookie = true;
+- e.bpf_cookie = get_bpf_cookie(link);
+- }
+- }
+-
+ bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
+ task->group_leader->comm);
+ bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
+diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
+index bbb570d..5692cf2 100644
+--- a/src/skeleton/pid_iter.h
++++ b/src/skeleton/pid_iter.h
+@@ -6,8 +6,6 @@
+ struct pid_iter_entry {
+ __u32 id;
+ int pid;
+- __u64 bpf_cookie;
+- bool has_bpf_cookie;
+ char comm[16];
+ };
+
+--
+2.30.2
+
--
2.30.2
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH v2 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-14 8:26 ` Shahab Vahedi
0 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi @ 2022-06-14 8:26 UTC (permalink / raw)
To: buildroot; +Cc: linux-snps-arc, Arnout Vandecappelle
Building bpftool on Debian 11 (bullseye) with kernel v5.10 fails:
-----------------------------------8<-----------------------------------
$ make
.
.
.
CLANG pid_iter.bpf.o
skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type
'struct bpf_perf_link'
perf_link = container_of(link, struct bpf_perf_link, link);
.
.
.
skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in
'struct perf_event'
return BPF_CORE_READ(event, bpf_cookie);
.
.
.
10 errors generated.
make: *** [Makefile:176: pid_iter.bpf.o] Error 1
----------------------------------->8-----------------------------------
There are changes in bpftool v6.8.0 that assumes the existence of
particular data structures in generated vmlinux.h that is obtained
from the host machine. See [1] for further details. This commit adds
a patch to revert that additional change in v6.8.0.
There's a patch series pending to be submitted upstream [2]. Hopefully,
those will take care of the problem if they land in the next release.
Changelog:
v1: Initial submission [3]
v2: Use a full fledged git patch for bpftool
[1]
https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
[2]
https://lore.kernel.org/bpf/20220421003152.339542-1-alobakin@pm.me/
[3]
https://lists.buildroot.org/pipermail/buildroot/2022-June/644819.html
Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
---
.../0002-revert-bpf_cookie-change.patch | 227 ++++++++++++++++++
1 file changed, 227 insertions(+)
create mode 100644 package/bpftool/0002-revert-bpf_cookie-change.patch
diff --git a/package/bpftool/0002-revert-bpf_cookie-change.patch b/package/bpftool/0002-revert-bpf_cookie-change.patch
new file mode 100644
index 0000000000..cb9ebdec41
--- /dev/null
+++ b/package/bpftool/0002-revert-bpf_cookie-change.patch
@@ -0,0 +1,227 @@
+From: Shahab Vahedi <shahab@synopsys.com>
+Date: Tue, 14 Jun 2022 10:12:21 +0200
+Subject: [PATCH] Revert commit "bpftool: Add bpf_cookie to link output"
+
+Building bpftool on Debian bullseye fails [1]. This patch
+reverts the offending commit [2].
+
+[1] Building release 6.8.0 on Debian 11
+https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
+
+[2] bpftool: Add bpf_cookie to link output
+https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=cbdaf71f
+
+Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
+diff --git a/src/main.h b/src/main.h
+index aa99ffa..2f2b638 100644
+--- a/src/main.h
++++ b/src/main.h
+@@ -111,9 +111,7 @@ struct obj_ref {
+
+ struct obj_refs {
+ int ref_cnt;
+- bool has_bpf_cookie;
+ struct obj_ref *refs;
+- __u64 bpf_cookie;
+ };
+
+ struct btf;
+diff --git a/src/pids.c b/src/pids.c
+index e2d00d3..57f0d1b 100644
+--- a/src/pids.c
++++ b/src/pids.c
+@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
+ ref->pid = e->pid;
+ memcpy(ref->comm, e->comm, sizeof(ref->comm));
+ refs->ref_cnt = 1;
+- refs->has_bpf_cookie = e->has_bpf_cookie;
+- refs->bpf_cookie = e->bpf_cookie;
+
+ err = hashmap__append(map, u32_as_hash_field(e->id), refs);
+ if (err)
+@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
+-
+ jsonw_name(json_writer, "pids");
+ jsonw_start_array(json_writer);
+ for (i = 0; i < refs->ref_cnt; i++) {
+@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
+-
+ printf("%s", prefix);
+ for (i = 0; i < refs->ref_cnt; i++) {
+ struct obj_ref *ref = &refs->refs[i];
+diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
+index eb05ea5..f70702f 100644
+--- a/src/skeleton/pid_iter.bpf.c
++++ b/src/skeleton/pid_iter.bpf.c
+@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
+ }
+ }
+
+-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
+-static __u64 get_bpf_cookie(struct bpf_link *link)
+-{
+- struct bpf_perf_link *perf_link;
+- struct perf_event *event;
+-
+- perf_link = container_of(link, struct bpf_perf_link, link);
+- event = BPF_CORE_READ(perf_link, perf_file, private_data);
+- return BPF_CORE_READ(event, bpf_cookie);
+-}
+-
+ SEC("iter/task_file")
+ int iter(struct bpf_iter__task_file *ctx)
+ {
+@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
+ if (file->f_op != fops)
+ return 0;
+
+- __builtin_memset(&e, 0, sizeof(e));
+ e.pid = task->tgid;
+ e.id = get_obj_id(file->private_data, obj_type);
+-
+- if (obj_type == BPF_OBJ_LINK) {
+- struct bpf_link *link = (struct bpf_link *) file->private_data;
+-
+- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
+- e.has_bpf_cookie = true;
+- e.bpf_cookie = get_bpf_cookie(link);
+- }
+- }
+-
+ bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
+ task->group_leader->comm);
+ bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
+diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
+index bbb570d..5692cf2 100644
+--- a/src/skeleton/pid_iter.h
++++ b/src/skeleton/pid_iter.h
+@@ -6,8 +6,6 @@
+ struct pid_iter_entry {
+ __u32 id;
+ int pid;
+- __u64 bpf_cookie;
+- bool has_bpf_cookie;
+ char comm[16];
+ };
+---
+ src/main.h | 2 --
+ src/pids.c | 8 --------
+ src/skeleton/pid_iter.bpf.c | 22 ----------------------
+ src/skeleton/pid_iter.h | 2 --
+ 4 files changed, 34 deletions(-)
+
+diff --git a/src/main.h b/src/main.h
+index aa99ffa..2f2b638 100644
+--- a/src/main.h
++++ b/src/main.h
+@@ -111,9 +111,7 @@ struct obj_ref {
+
+ struct obj_refs {
+ int ref_cnt;
+- bool has_bpf_cookie;
+ struct obj_ref *refs;
+- __u64 bpf_cookie;
+ };
+
+ struct btf;
+diff --git a/src/pids.c b/src/pids.c
+index e2d00d3..57f0d1b 100644
+--- a/src/pids.c
++++ b/src/pids.c
+@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
+ ref->pid = e->pid;
+ memcpy(ref->comm, e->comm, sizeof(ref->comm));
+ refs->ref_cnt = 1;
+- refs->has_bpf_cookie = e->has_bpf_cookie;
+- refs->bpf_cookie = e->bpf_cookie;
+
+ err = hashmap__append(map, u32_as_hash_field(e->id), refs);
+ if (err)
+@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
+-
+ jsonw_name(json_writer, "pids");
+ jsonw_start_array(json_writer);
+ for (i = 0; i < refs->ref_cnt; i++) {
+@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
+-
+ printf("%s", prefix);
+ for (i = 0; i < refs->ref_cnt; i++) {
+ struct obj_ref *ref = &refs->refs[i];
+diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
+index eb05ea5..f70702f 100644
+--- a/src/skeleton/pid_iter.bpf.c
++++ b/src/skeleton/pid_iter.bpf.c
+@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
+ }
+ }
+
+-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
+-static __u64 get_bpf_cookie(struct bpf_link *link)
+-{
+- struct bpf_perf_link *perf_link;
+- struct perf_event *event;
+-
+- perf_link = container_of(link, struct bpf_perf_link, link);
+- event = BPF_CORE_READ(perf_link, perf_file, private_data);
+- return BPF_CORE_READ(event, bpf_cookie);
+-}
+-
+ SEC("iter/task_file")
+ int iter(struct bpf_iter__task_file *ctx)
+ {
+@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
+ if (file->f_op != fops)
+ return 0;
+
+- __builtin_memset(&e, 0, sizeof(e));
+ e.pid = task->tgid;
+ e.id = get_obj_id(file->private_data, obj_type);
+-
+- if (obj_type == BPF_OBJ_LINK) {
+- struct bpf_link *link = (struct bpf_link *) file->private_data;
+-
+- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
+- e.has_bpf_cookie = true;
+- e.bpf_cookie = get_bpf_cookie(link);
+- }
+- }
+-
+ bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
+ task->group_leader->comm);
+ bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
+diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
+index bbb570d..5692cf2 100644
+--- a/src/skeleton/pid_iter.h
++++ b/src/skeleton/pid_iter.h
+@@ -6,8 +6,6 @@
+ struct pid_iter_entry {
+ __u32 id;
+ int pid;
+- __u64 bpf_cookie;
+- bool has_bpf_cookie;
+ char comm[16];
+ };
+
+--
+2.30.2
+
--
2.30.2
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-14 8:26 ` Shahab Vahedi
@ 2022-06-14 9:31 ` Shahab Vahedi
-1 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi via buildroot @ 2022-06-14 9:31 UTC (permalink / raw)
To: buildroot; +Cc: linux-snps-arc
Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
fails:
-----------------------------------8<-----------------------------------
$ make
.
.
.
CLANG pid_iter.bpf.o
skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type
'struct bpf_perf_link'
perf_link = container_of(link, struct bpf_perf_link, link);
.
.
.
skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in
'struct perf_event'
return BPF_CORE_READ(event, bpf_cookie);
.
.
.
10 errors generated.
make: *** [Makefile:176: pid_iter.bpf.o] Error 1
----------------------------------->8-----------------------------------
There are changes in bpftool v6.8.0 that assumes the existence of
particular data structures in generated vmlinux.h that is obtained
from the host machine. See [1] for further details. This commit adds
a patch to revert that additional change in v6.8.0.
There's a patch series pending to be submitted upstream [2]. Hopefully,
those will take care of the problem if they land in the next release.
Changelog:
v1: Initial submission [3]
v2: Use a full fledged git patch for bpftool [4]
v3: Fix the snafu that resulted in malformed patch file
[1]
https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
[2]
https://lore.kernel.org/bpf/20220421003152.339542-1-alobakin@pm.me/
[3]
https://lists.buildroot.org/pipermail/buildroot/2022-June/644819.html
[4]
https://lists.buildroot.org/pipermail/buildroot/2022-June/644824.html
Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
---
.../0002-revert-bpf_cookie-change.patch | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 package/bpftool/0002-revert-bpf_cookie-change.patch
diff --git a/package/bpftool/0002-revert-bpf_cookie-change.patch b/package/bpftool/0002-revert-bpf_cookie-change.patch
new file mode 100644
index 0000000000..6f9579bd23
--- /dev/null
+++ b/package/bpftool/0002-revert-bpf_cookie-change.patch
@@ -0,0 +1,129 @@
+From d7c78d1e38cde73c85b491a833f0e6e3f0d62654 Mon Sep 17 00:00:00 2001
+From: Shahab Vahedi <shahab@synopsys.com>
+Date: Tue, 14 Jun 2022 10:12:21 +0200
+Subject: [PATCH] Revert commit "bpftool: Add bpf_cookie to link output"
+
+Building bpftool on a Debian bullseye with clang-11 fails [1].
+This patch reverts the offending commit [2]. If clang-11 is not
+installed, then the "co-re" feature of bpf will not be enabled
+and the issue remains dormant.
+
+[1] Building release 6.8.0 on Debian 11
+https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
+
+[2] bpftool: Add bpf_cookie to link output
+https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=cbdaf71f
+
+Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
+---
+ src/main.h | 2 --
+ src/pids.c | 8 --------
+ src/skeleton/pid_iter.bpf.c | 22 ----------------------
+ src/skeleton/pid_iter.h | 2 --
+ 4 files changed, 34 deletions(-)
+
+diff --git a/src/main.h b/src/main.h
+index aa99ffa..2f2b638 100644
+--- a/src/main.h
++++ b/src/main.h
+@@ -111,9 +111,7 @@ struct obj_ref {
+
+ struct obj_refs {
+ int ref_cnt;
+- bool has_bpf_cookie;
+ struct obj_ref *refs;
+- __u64 bpf_cookie;
+ };
+
+ struct btf;
+diff --git a/src/pids.c b/src/pids.c
+index e2d00d3..57f0d1b 100644
+--- a/src/pids.c
++++ b/src/pids.c
+@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
+ ref->pid = e->pid;
+ memcpy(ref->comm, e->comm, sizeof(ref->comm));
+ refs->ref_cnt = 1;
+- refs->has_bpf_cookie = e->has_bpf_cookie;
+- refs->bpf_cookie = e->bpf_cookie;
+
+ err = hashmap__append(map, u32_as_hash_field(e->id), refs);
+ if (err)
+@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
+-
+ jsonw_name(json_writer, "pids");
+ jsonw_start_array(json_writer);
+ for (i = 0; i < refs->ref_cnt; i++) {
+@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
+-
+ printf("%s", prefix);
+ for (i = 0; i < refs->ref_cnt; i++) {
+ struct obj_ref *ref = &refs->refs[i];
+diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
+index eb05ea5..f70702f 100644
+--- a/src/skeleton/pid_iter.bpf.c
++++ b/src/skeleton/pid_iter.bpf.c
+@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
+ }
+ }
+
+-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
+-static __u64 get_bpf_cookie(struct bpf_link *link)
+-{
+- struct bpf_perf_link *perf_link;
+- struct perf_event *event;
+-
+- perf_link = container_of(link, struct bpf_perf_link, link);
+- event = BPF_CORE_READ(perf_link, perf_file, private_data);
+- return BPF_CORE_READ(event, bpf_cookie);
+-}
+-
+ SEC("iter/task_file")
+ int iter(struct bpf_iter__task_file *ctx)
+ {
+@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
+ if (file->f_op != fops)
+ return 0;
+
+- __builtin_memset(&e, 0, sizeof(e));
+ e.pid = task->tgid;
+ e.id = get_obj_id(file->private_data, obj_type);
+-
+- if (obj_type == BPF_OBJ_LINK) {
+- struct bpf_link *link = (struct bpf_link *) file->private_data;
+-
+- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
+- e.has_bpf_cookie = true;
+- e.bpf_cookie = get_bpf_cookie(link);
+- }
+- }
+-
+ bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
+ task->group_leader->comm);
+ bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
+diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
+index bbb570d..5692cf2 100644
+--- a/src/skeleton/pid_iter.h
++++ b/src/skeleton/pid_iter.h
+@@ -6,8 +6,6 @@
+ struct pid_iter_entry {
+ __u32 id;
+ int pid;
+- __u64 bpf_cookie;
+- bool has_bpf_cookie;
+ char comm[16];
+ };
+
+--
+2.30.2
+
--
2.30.2
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-14 9:31 ` Shahab Vahedi
0 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi @ 2022-06-14 9:31 UTC (permalink / raw)
To: buildroot; +Cc: linux-snps-arc, Arnout Vandecappelle
Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
fails:
-----------------------------------8<-----------------------------------
$ make
.
.
.
CLANG pid_iter.bpf.o
skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type
'struct bpf_perf_link'
perf_link = container_of(link, struct bpf_perf_link, link);
.
.
.
skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in
'struct perf_event'
return BPF_CORE_READ(event, bpf_cookie);
.
.
.
10 errors generated.
make: *** [Makefile:176: pid_iter.bpf.o] Error 1
----------------------------------->8-----------------------------------
There are changes in bpftool v6.8.0 that assumes the existence of
particular data structures in generated vmlinux.h that is obtained
from the host machine. See [1] for further details. This commit adds
a patch to revert that additional change in v6.8.0.
There's a patch series pending to be submitted upstream [2]. Hopefully,
those will take care of the problem if they land in the next release.
Changelog:
v1: Initial submission [3]
v2: Use a full fledged git patch for bpftool [4]
v3: Fix the snafu that resulted in malformed patch file
[1]
https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
[2]
https://lore.kernel.org/bpf/20220421003152.339542-1-alobakin@pm.me/
[3]
https://lists.buildroot.org/pipermail/buildroot/2022-June/644819.html
[4]
https://lists.buildroot.org/pipermail/buildroot/2022-June/644824.html
Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
---
.../0002-revert-bpf_cookie-change.patch | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 package/bpftool/0002-revert-bpf_cookie-change.patch
diff --git a/package/bpftool/0002-revert-bpf_cookie-change.patch b/package/bpftool/0002-revert-bpf_cookie-change.patch
new file mode 100644
index 0000000000..6f9579bd23
--- /dev/null
+++ b/package/bpftool/0002-revert-bpf_cookie-change.patch
@@ -0,0 +1,129 @@
+From d7c78d1e38cde73c85b491a833f0e6e3f0d62654 Mon Sep 17 00:00:00 2001
+From: Shahab Vahedi <shahab@synopsys.com>
+Date: Tue, 14 Jun 2022 10:12:21 +0200
+Subject: [PATCH] Revert commit "bpftool: Add bpf_cookie to link output"
+
+Building bpftool on a Debian bullseye with clang-11 fails [1].
+This patch reverts the offending commit [2]. If clang-11 is not
+installed, then the "co-re" feature of bpf will not be enabled
+and the issue remains dormant.
+
+[1] Building release 6.8.0 on Debian 11
+https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
+
+[2] bpftool: Add bpf_cookie to link output
+https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=cbdaf71f
+
+Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
+---
+ src/main.h | 2 --
+ src/pids.c | 8 --------
+ src/skeleton/pid_iter.bpf.c | 22 ----------------------
+ src/skeleton/pid_iter.h | 2 --
+ 4 files changed, 34 deletions(-)
+
+diff --git a/src/main.h b/src/main.h
+index aa99ffa..2f2b638 100644
+--- a/src/main.h
++++ b/src/main.h
+@@ -111,9 +111,7 @@ struct obj_ref {
+
+ struct obj_refs {
+ int ref_cnt;
+- bool has_bpf_cookie;
+ struct obj_ref *refs;
+- __u64 bpf_cookie;
+ };
+
+ struct btf;
+diff --git a/src/pids.c b/src/pids.c
+index e2d00d3..57f0d1b 100644
+--- a/src/pids.c
++++ b/src/pids.c
+@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
+ ref->pid = e->pid;
+ memcpy(ref->comm, e->comm, sizeof(ref->comm));
+ refs->ref_cnt = 1;
+- refs->has_bpf_cookie = e->has_bpf_cookie;
+- refs->bpf_cookie = e->bpf_cookie;
+
+ err = hashmap__append(map, u32_as_hash_field(e->id), refs);
+ if (err)
+@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
+-
+ jsonw_name(json_writer, "pids");
+ jsonw_start_array(json_writer);
+ for (i = 0; i < refs->ref_cnt; i++) {
+@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
+-
+ printf("%s", prefix);
+ for (i = 0; i < refs->ref_cnt; i++) {
+ struct obj_ref *ref = &refs->refs[i];
+diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
+index eb05ea5..f70702f 100644
+--- a/src/skeleton/pid_iter.bpf.c
++++ b/src/skeleton/pid_iter.bpf.c
+@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
+ }
+ }
+
+-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
+-static __u64 get_bpf_cookie(struct bpf_link *link)
+-{
+- struct bpf_perf_link *perf_link;
+- struct perf_event *event;
+-
+- perf_link = container_of(link, struct bpf_perf_link, link);
+- event = BPF_CORE_READ(perf_link, perf_file, private_data);
+- return BPF_CORE_READ(event, bpf_cookie);
+-}
+-
+ SEC("iter/task_file")
+ int iter(struct bpf_iter__task_file *ctx)
+ {
+@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
+ if (file->f_op != fops)
+ return 0;
+
+- __builtin_memset(&e, 0, sizeof(e));
+ e.pid = task->tgid;
+ e.id = get_obj_id(file->private_data, obj_type);
+-
+- if (obj_type == BPF_OBJ_LINK) {
+- struct bpf_link *link = (struct bpf_link *) file->private_data;
+-
+- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
+- e.has_bpf_cookie = true;
+- e.bpf_cookie = get_bpf_cookie(link);
+- }
+- }
+-
+ bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
+ task->group_leader->comm);
+ bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
+diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
+index bbb570d..5692cf2 100644
+--- a/src/skeleton/pid_iter.h
++++ b/src/skeleton/pid_iter.h
+@@ -6,8 +6,6 @@
+ struct pid_iter_entry {
+ __u32 id;
+ int pid;
+- __u64 bpf_cookie;
+- bool has_bpf_cookie;
+ char comm[16];
+ };
+
+--
+2.30.2
+
--
2.30.2
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-14 9:31 ` Shahab Vahedi
@ 2022-06-14 17:14 ` Arnout Vandecappelle
-1 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2022-06-14 17:14 UTC (permalink / raw)
To: Shahab Vahedi, buildroot; +Cc: linux-snps-arc
On 14/06/2022 11:31, Shahab Vahedi wrote:
> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
How do you build host-bpftool with clang in Buildroot context? HOSTCC is set
to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot
command line? I'm not sure if we are really interested in carrying fixes for
such exotic and not-really-supported situations...
> fails:
>
> -----------------------------------8<-----------------------------------
> $ make
> .
> .
> .
> CLANG pid_iter.bpf.o
> skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type
> 'struct bpf_perf_link'
> perf_link = container_of(link, struct bpf_perf_link, link);
> .
> .
> .
> skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in
> 'struct perf_event'
> return BPF_CORE_READ(event, bpf_cookie);
> .
> .
> .
> 10 errors generated.
> make: *** [Makefile:176: pid_iter.bpf.o] Error 1
> ----------------------------------->8-----------------------------------
>
> There are changes in bpftool v6.8.0 that assumes the existence of
> particular data structures in generated vmlinux.h that is obtained
> from the host machine. See [1] for further details. This commit adds
> a patch to revert that additional change in v6.8.0.
>
> There's a patch series pending to be submitted upstream [2]. Hopefully,
> those will take care of the problem if they land in the next release.
>
> Changelog:
Patch changelog should be under the --- line, it's not meant to be part of the
git history. But of course that means you need to put the references [1][2]
above the --- line.
(No need to resend for this or any of my other comments, just FYI for future
submissions.)
> v1: Initial submission [3]
It's nice, but not really necessary to have a reference to the old versions.
They're easy enough to find back.
> v2: Use a full fledged git patch for bpftool [4]
> v3: Fix the snafu that resulted in malformed patch file
>
> [1]
> https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
>
> [2]
> https://lore.kernel.org/bpf/20220421003152.339542-1-alobakin@pm.me/
>
> [3]
> https://lists.buildroot.org/pipermail/buildroot/2022-June/644819.html
To refer to a buildroot patch, it's nicer to refer to patchwork, i.e.
https://patchwork.ozlabs.org/project/buildroot/patch/97ea44bb-58fe-d6cb-6c79-9be0b245f2c6@synopsys.com/
Regards,
Arnout
>
> [4]
> https://lists.buildroot.org/pipermail/buildroot/2022-June/644824.html
>
> Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
> ---
> .../0002-revert-bpf_cookie-change.patch | 129 ++++++++++++++++++
> 1 file changed, 129 insertions(+)
> create mode 100644 package/bpftool/0002-revert-bpf_cookie-change.patch
>
> diff --git a/package/bpftool/0002-revert-bpf_cookie-change.patch b/package/bpftool/0002-revert-bpf_cookie-change.patch
> new file mode 100644
> index 0000000000..6f9579bd23
> --- /dev/null
> +++ b/package/bpftool/0002-revert-bpf_cookie-change.patch
> @@ -0,0 +1,129 @@
> +From d7c78d1e38cde73c85b491a833f0e6e3f0d62654 Mon Sep 17 00:00:00 2001
> +From: Shahab Vahedi <shahab@synopsys.com>
> +Date: Tue, 14 Jun 2022 10:12:21 +0200
> +Subject: [PATCH] Revert commit "bpftool: Add bpf_cookie to link output"
> +
> +Building bpftool on a Debian bullseye with clang-11 fails [1].
> +This patch reverts the offending commit [2]. If clang-11 is not
> +installed, then the "co-re" feature of bpf will not be enabled
> +and the issue remains dormant.
> +
> +[1] Building release 6.8.0 on Debian 11
> +https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
> +
> +[2] bpftool: Add bpf_cookie to link output
> +https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=cbdaf71f
> +
> +Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
> +---
> + src/main.h | 2 --
> + src/pids.c | 8 --------
> + src/skeleton/pid_iter.bpf.c | 22 ----------------------
> + src/skeleton/pid_iter.h | 2 --
> + 4 files changed, 34 deletions(-)
> +
> +diff --git a/src/main.h b/src/main.h
> +index aa99ffa..2f2b638 100644
> +--- a/src/main.h
> ++++ b/src/main.h
> +@@ -111,9 +111,7 @@ struct obj_ref {
> +
> + struct obj_refs {
> + int ref_cnt;
> +- bool has_bpf_cookie;
> + struct obj_ref *refs;
> +- __u64 bpf_cookie;
> + };
> +
> + struct btf;
> +diff --git a/src/pids.c b/src/pids.c
> +index e2d00d3..57f0d1b 100644
> +--- a/src/pids.c
> ++++ b/src/pids.c
> +@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
> + ref->pid = e->pid;
> + memcpy(ref->comm, e->comm, sizeof(ref->comm));
> + refs->ref_cnt = 1;
> +- refs->has_bpf_cookie = e->has_bpf_cookie;
> +- refs->bpf_cookie = e->bpf_cookie;
> +
> + err = hashmap__append(map, u32_as_hash_field(e->id), refs);
> + if (err)
> +@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
> + if (refs->ref_cnt == 0)
> + break;
> +
> +- if (refs->has_bpf_cookie)
> +- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
> +-
> + jsonw_name(json_writer, "pids");
> + jsonw_start_array(json_writer);
> + for (i = 0; i < refs->ref_cnt; i++) {
> +@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
> + if (refs->ref_cnt == 0)
> + break;
> +
> +- if (refs->has_bpf_cookie)
> +- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
> +-
> + printf("%s", prefix);
> + for (i = 0; i < refs->ref_cnt; i++) {
> + struct obj_ref *ref = &refs->refs[i];
> +diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
> +index eb05ea5..f70702f 100644
> +--- a/src/skeleton/pid_iter.bpf.c
> ++++ b/src/skeleton/pid_iter.bpf.c
> +@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
> + }
> + }
> +
> +-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
> +-static __u64 get_bpf_cookie(struct bpf_link *link)
> +-{
> +- struct bpf_perf_link *perf_link;
> +- struct perf_event *event;
> +-
> +- perf_link = container_of(link, struct bpf_perf_link, link);
> +- event = BPF_CORE_READ(perf_link, perf_file, private_data);
> +- return BPF_CORE_READ(event, bpf_cookie);
> +-}
> +-
> + SEC("iter/task_file")
> + int iter(struct bpf_iter__task_file *ctx)
> + {
> +@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
> + if (file->f_op != fops)
> + return 0;
> +
> +- __builtin_memset(&e, 0, sizeof(e));
> + e.pid = task->tgid;
> + e.id = get_obj_id(file->private_data, obj_type);
> +-
> +- if (obj_type == BPF_OBJ_LINK) {
> +- struct bpf_link *link = (struct bpf_link *) file->private_data;
> +-
> +- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
> +- e.has_bpf_cookie = true;
> +- e.bpf_cookie = get_bpf_cookie(link);
> +- }
> +- }
> +-
> + bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
> + task->group_leader->comm);
> + bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
> +diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
> +index bbb570d..5692cf2 100644
> +--- a/src/skeleton/pid_iter.h
> ++++ b/src/skeleton/pid_iter.h
> +@@ -6,8 +6,6 @@
> + struct pid_iter_entry {
> + __u32 id;
> + int pid;
> +- __u64 bpf_cookie;
> +- bool has_bpf_cookie;
> + char comm[16];
> + };
> +
> +--
> +2.30.2
> +
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-14 17:14 ` Arnout Vandecappelle
0 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2022-06-14 17:14 UTC (permalink / raw)
To: Shahab Vahedi, buildroot; +Cc: linux-snps-arc
On 14/06/2022 11:31, Shahab Vahedi wrote:
> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
How do you build host-bpftool with clang in Buildroot context? HOSTCC is set
to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot
command line? I'm not sure if we are really interested in carrying fixes for
such exotic and not-really-supported situations...
> fails:
>
> -----------------------------------8<-----------------------------------
> $ make
> .
> .
> .
> CLANG pid_iter.bpf.o
> skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type
> 'struct bpf_perf_link'
> perf_link = container_of(link, struct bpf_perf_link, link);
> .
> .
> .
> skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in
> 'struct perf_event'
> return BPF_CORE_READ(event, bpf_cookie);
> .
> .
> .
> 10 errors generated.
> make: *** [Makefile:176: pid_iter.bpf.o] Error 1
> ----------------------------------->8-----------------------------------
>
> There are changes in bpftool v6.8.0 that assumes the existence of
> particular data structures in generated vmlinux.h that is obtained
> from the host machine. See [1] for further details. This commit adds
> a patch to revert that additional change in v6.8.0.
>
> There's a patch series pending to be submitted upstream [2]. Hopefully,
> those will take care of the problem if they land in the next release.
>
> Changelog:
Patch changelog should be under the --- line, it's not meant to be part of the
git history. But of course that means you need to put the references [1][2]
above the --- line.
(No need to resend for this or any of my other comments, just FYI for future
submissions.)
> v1: Initial submission [3]
It's nice, but not really necessary to have a reference to the old versions.
They're easy enough to find back.
> v2: Use a full fledged git patch for bpftool [4]
> v3: Fix the snafu that resulted in malformed patch file
>
> [1]
> https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
>
> [2]
> https://lore.kernel.org/bpf/20220421003152.339542-1-alobakin@pm.me/
>
> [3]
> https://lists.buildroot.org/pipermail/buildroot/2022-June/644819.html
To refer to a buildroot patch, it's nicer to refer to patchwork, i.e.
https://patchwork.ozlabs.org/project/buildroot/patch/97ea44bb-58fe-d6cb-6c79-9be0b245f2c6@synopsys.com/
Regards,
Arnout
>
> [4]
> https://lists.buildroot.org/pipermail/buildroot/2022-June/644824.html
>
> Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
> ---
> .../0002-revert-bpf_cookie-change.patch | 129 ++++++++++++++++++
> 1 file changed, 129 insertions(+)
> create mode 100644 package/bpftool/0002-revert-bpf_cookie-change.patch
>
> diff --git a/package/bpftool/0002-revert-bpf_cookie-change.patch b/package/bpftool/0002-revert-bpf_cookie-change.patch
> new file mode 100644
> index 0000000000..6f9579bd23
> --- /dev/null
> +++ b/package/bpftool/0002-revert-bpf_cookie-change.patch
> @@ -0,0 +1,129 @@
> +From d7c78d1e38cde73c85b491a833f0e6e3f0d62654 Mon Sep 17 00:00:00 2001
> +From: Shahab Vahedi <shahab@synopsys.com>
> +Date: Tue, 14 Jun 2022 10:12:21 +0200
> +Subject: [PATCH] Revert commit "bpftool: Add bpf_cookie to link output"
> +
> +Building bpftool on a Debian bullseye with clang-11 fails [1].
> +This patch reverts the offending commit [2]. If clang-11 is not
> +installed, then the "co-re" feature of bpf will not be enabled
> +and the issue remains dormant.
> +
> +[1] Building release 6.8.0 on Debian 11
> +https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
> +
> +[2] bpftool: Add bpf_cookie to link output
> +https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=cbdaf71f
> +
> +Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
> +---
> + src/main.h | 2 --
> + src/pids.c | 8 --------
> + src/skeleton/pid_iter.bpf.c | 22 ----------------------
> + src/skeleton/pid_iter.h | 2 --
> + 4 files changed, 34 deletions(-)
> +
> +diff --git a/src/main.h b/src/main.h
> +index aa99ffa..2f2b638 100644
> +--- a/src/main.h
> ++++ b/src/main.h
> +@@ -111,9 +111,7 @@ struct obj_ref {
> +
> + struct obj_refs {
> + int ref_cnt;
> +- bool has_bpf_cookie;
> + struct obj_ref *refs;
> +- __u64 bpf_cookie;
> + };
> +
> + struct btf;
> +diff --git a/src/pids.c b/src/pids.c
> +index e2d00d3..57f0d1b 100644
> +--- a/src/pids.c
> ++++ b/src/pids.c
> +@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
> + ref->pid = e->pid;
> + memcpy(ref->comm, e->comm, sizeof(ref->comm));
> + refs->ref_cnt = 1;
> +- refs->has_bpf_cookie = e->has_bpf_cookie;
> +- refs->bpf_cookie = e->bpf_cookie;
> +
> + err = hashmap__append(map, u32_as_hash_field(e->id), refs);
> + if (err)
> +@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
> + if (refs->ref_cnt == 0)
> + break;
> +
> +- if (refs->has_bpf_cookie)
> +- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
> +-
> + jsonw_name(json_writer, "pids");
> + jsonw_start_array(json_writer);
> + for (i = 0; i < refs->ref_cnt; i++) {
> +@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
> + if (refs->ref_cnt == 0)
> + break;
> +
> +- if (refs->has_bpf_cookie)
> +- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
> +-
> + printf("%s", prefix);
> + for (i = 0; i < refs->ref_cnt; i++) {
> + struct obj_ref *ref = &refs->refs[i];
> +diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
> +index eb05ea5..f70702f 100644
> +--- a/src/skeleton/pid_iter.bpf.c
> ++++ b/src/skeleton/pid_iter.bpf.c
> +@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
> + }
> + }
> +
> +-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
> +-static __u64 get_bpf_cookie(struct bpf_link *link)
> +-{
> +- struct bpf_perf_link *perf_link;
> +- struct perf_event *event;
> +-
> +- perf_link = container_of(link, struct bpf_perf_link, link);
> +- event = BPF_CORE_READ(perf_link, perf_file, private_data);
> +- return BPF_CORE_READ(event, bpf_cookie);
> +-}
> +-
> + SEC("iter/task_file")
> + int iter(struct bpf_iter__task_file *ctx)
> + {
> +@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
> + if (file->f_op != fops)
> + return 0;
> +
> +- __builtin_memset(&e, 0, sizeof(e));
> + e.pid = task->tgid;
> + e.id = get_obj_id(file->private_data, obj_type);
> +-
> +- if (obj_type == BPF_OBJ_LINK) {
> +- struct bpf_link *link = (struct bpf_link *) file->private_data;
> +-
> +- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
> +- e.has_bpf_cookie = true;
> +- e.bpf_cookie = get_bpf_cookie(link);
> +- }
> +- }
> +-
> + bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
> + task->group_leader->comm);
> + bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
> +diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
> +index bbb570d..5692cf2 100644
> +--- a/src/skeleton/pid_iter.h
> ++++ b/src/skeleton/pid_iter.h
> +@@ -6,8 +6,6 @@
> + struct pid_iter_entry {
> + __u32 id;
> + int pid;
> +- __u64 bpf_cookie;
> +- bool has_bpf_cookie;
> + char comm[16];
> + };
> +
> +--
> +2.30.2
> +
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-14 17:14 ` Arnout Vandecappelle
@ 2022-06-14 17:27 ` Arnout Vandecappelle
-1 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2022-06-14 17:27 UTC (permalink / raw)
To: Shahab Vahedi, buildroot; +Cc: linux-snps-arc
On 14/06/2022 19:14, Arnout Vandecappelle wrote:
> (No need to resend for this or any of my other comments, just FYI for future
> submissions.)
Actually, the patch didn't appear on patchwork for some reason. It analyzed it
as a reply to the previous version of the patch. So you will have to resend it
after all.
Regards,
Arnout
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-14 17:27 ` Arnout Vandecappelle
0 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2022-06-14 17:27 UTC (permalink / raw)
To: Shahab Vahedi, buildroot; +Cc: linux-snps-arc
On 14/06/2022 19:14, Arnout Vandecappelle wrote:
> (No need to resend for this or any of my other comments, just FYI for future
> submissions.)
Actually, the patch didn't appear on patchwork for some reason. It analyzed it
as a reply to the previous version of the patch. So you will have to resend it
after all.
Regards,
Arnout
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-13 21:30 [Buildroot] [PATCH] package/bpftool: revert bpf_cookie patch to allow building Shahab Vahedi via buildroot
@ 2022-06-15 10:57 ` Shahab Vahedi
2022-06-15 10:57 ` Shahab Vahedi
1 sibling, 0 replies; 43+ messages in thread
From: Shahab Vahedi via buildroot @ 2022-06-15 10:57 UTC (permalink / raw)
To: buildroot; +Cc: linux-snps-arc, Shahab Vahedi
Building bpftool on Debian 11 (bullseye) with kernel v5.10 fails:
-----------------------------------8<-----------------------------------
$ make
.
.
.
CLANG pid_iter.bpf.o
skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type
'struct bpf_perf_link'
perf_link = container_of(link, struct bpf_perf_link, link);
.
.
.
skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in
'struct perf_event'
return BPF_CORE_READ(event, bpf_cookie);
.
.
.
10 errors generated.
make: *** [Makefile:176: pid_iter.bpf.o] Error 1
----------------------------------->8-----------------------------------
To be clearer about the setup, there is a clang (11) installed on this
system. bpftool's build process enables "co-re" feature (Compile-Once,
Run-Everywhere) if the clang compiler is new enough to support
BTF_KIND_VAR [1]. When that happens, bpftool will bootstrap itself:
build/bootstrap/libbpf.a. This bootstrap part is about those *.bpf.c
programs and are only built by invoking clang [2], irrespective of the
compiler used to build the rest of the bpftool. To sum it up, to
reproduce the issue, all you need is having the "co-re" feature
enabled and a kernel that does not provide all the data structures
expected.
There are changes in bpftool v6.8.0 that assumes the existence of
particular data structures in generated vmlinux.h that is obtained
from the host machine. See [3] for further details. This commit adds
a patch to revert that additional change in v6.8.0.
There's a patch series pending to be submitted upstream [4]. Hopefully,
those will take care of the problem if they land in the next release.
[1] Checking for the clang support
https://github.com/libbpf/bpftool/blob/d4469819d1d639ae2354f3d2ddd10377f081a576/src/Makefile.feature#L12
[2] Using clang to bootstrap
https://github.com/libbpf/bpftool/blob/d4469819d1d639ae2354f3d2ddd10377f081a576/src/Makefile#L175
[3] Question about the problem
https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
[4] Pending patch series
https://lore.kernel.org/bpf/20220421003152.339542-1-alobakin@pm.me/
Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
---
Changelog:
v1: Initial submission
v2: Use a full fledged git patch for bpftool
v3: Fix the snafu that resulted in malformed patch file
v4: Reword the commit message to make it clearer
.../0002-revert-bpf_cookie-change.patch | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 package/bpftool/0002-revert-bpf_cookie-change.patch
diff --git a/package/bpftool/0002-revert-bpf_cookie-change.patch b/package/bpftool/0002-revert-bpf_cookie-change.patch
new file mode 100644
index 0000000000..6f9579bd23
--- /dev/null
+++ b/package/bpftool/0002-revert-bpf_cookie-change.patch
@@ -0,0 +1,129 @@
+From d7c78d1e38cde73c85b491a833f0e6e3f0d62654 Mon Sep 17 00:00:00 2001
+From: Shahab Vahedi <shahab@synopsys.com>
+Date: Tue, 14 Jun 2022 10:12:21 +0200
+Subject: [PATCH] Revert commit "bpftool: Add bpf_cookie to link output"
+
+Building bpftool on a Debian bullseye with clang-11 fails [1].
+This patch reverts the offending commit [2]. If clang-11 is not
+installed, then the "co-re" feature of bpf will not be enabled
+and the issue remains dormant.
+
+[1] Building release 6.8.0 on Debian 11
+https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
+
+[2] bpftool: Add bpf_cookie to link output
+https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=cbdaf71f
+
+Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
+---
+ src/main.h | 2 --
+ src/pids.c | 8 --------
+ src/skeleton/pid_iter.bpf.c | 22 ----------------------
+ src/skeleton/pid_iter.h | 2 --
+ 4 files changed, 34 deletions(-)
+
+diff --git a/src/main.h b/src/main.h
+index aa99ffa..2f2b638 100644
+--- a/src/main.h
++++ b/src/main.h
+@@ -111,9 +111,7 @@ struct obj_ref {
+
+ struct obj_refs {
+ int ref_cnt;
+- bool has_bpf_cookie;
+ struct obj_ref *refs;
+- __u64 bpf_cookie;
+ };
+
+ struct btf;
+diff --git a/src/pids.c b/src/pids.c
+index e2d00d3..57f0d1b 100644
+--- a/src/pids.c
++++ b/src/pids.c
+@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
+ ref->pid = e->pid;
+ memcpy(ref->comm, e->comm, sizeof(ref->comm));
+ refs->ref_cnt = 1;
+- refs->has_bpf_cookie = e->has_bpf_cookie;
+- refs->bpf_cookie = e->bpf_cookie;
+
+ err = hashmap__append(map, u32_as_hash_field(e->id), refs);
+ if (err)
+@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
+-
+ jsonw_name(json_writer, "pids");
+ jsonw_start_array(json_writer);
+ for (i = 0; i < refs->ref_cnt; i++) {
+@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
+-
+ printf("%s", prefix);
+ for (i = 0; i < refs->ref_cnt; i++) {
+ struct obj_ref *ref = &refs->refs[i];
+diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
+index eb05ea5..f70702f 100644
+--- a/src/skeleton/pid_iter.bpf.c
++++ b/src/skeleton/pid_iter.bpf.c
+@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
+ }
+ }
+
+-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
+-static __u64 get_bpf_cookie(struct bpf_link *link)
+-{
+- struct bpf_perf_link *perf_link;
+- struct perf_event *event;
+-
+- perf_link = container_of(link, struct bpf_perf_link, link);
+- event = BPF_CORE_READ(perf_link, perf_file, private_data);
+- return BPF_CORE_READ(event, bpf_cookie);
+-}
+-
+ SEC("iter/task_file")
+ int iter(struct bpf_iter__task_file *ctx)
+ {
+@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
+ if (file->f_op != fops)
+ return 0;
+
+- __builtin_memset(&e, 0, sizeof(e));
+ e.pid = task->tgid;
+ e.id = get_obj_id(file->private_data, obj_type);
+-
+- if (obj_type == BPF_OBJ_LINK) {
+- struct bpf_link *link = (struct bpf_link *) file->private_data;
+-
+- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
+- e.has_bpf_cookie = true;
+- e.bpf_cookie = get_bpf_cookie(link);
+- }
+- }
+-
+ bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
+ task->group_leader->comm);
+ bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
+diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
+index bbb570d..5692cf2 100644
+--- a/src/skeleton/pid_iter.h
++++ b/src/skeleton/pid_iter.h
+@@ -6,8 +6,6 @@
+ struct pid_iter_entry {
+ __u32 id;
+ int pid;
+- __u64 bpf_cookie;
+- bool has_bpf_cookie;
+ char comm[16];
+ };
+
+--
+2.30.2
+
--
2.30.2
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-15 10:57 ` Shahab Vahedi
0 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi @ 2022-06-15 10:57 UTC (permalink / raw)
To: buildroot; +Cc: Shahab Vahedi, Arnout Vandecappelle, linux-snps-arc
Building bpftool on Debian 11 (bullseye) with kernel v5.10 fails:
-----------------------------------8<-----------------------------------
$ make
.
.
.
CLANG pid_iter.bpf.o
skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type
'struct bpf_perf_link'
perf_link = container_of(link, struct bpf_perf_link, link);
.
.
.
skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in
'struct perf_event'
return BPF_CORE_READ(event, bpf_cookie);
.
.
.
10 errors generated.
make: *** [Makefile:176: pid_iter.bpf.o] Error 1
----------------------------------->8-----------------------------------
To be clearer about the setup, there is a clang (11) installed on this
system. bpftool's build process enables "co-re" feature (Compile-Once,
Run-Everywhere) if the clang compiler is new enough to support
BTF_KIND_VAR [1]. When that happens, bpftool will bootstrap itself:
build/bootstrap/libbpf.a. This bootstrap part is about those *.bpf.c
programs and are only built by invoking clang [2], irrespective of the
compiler used to build the rest of the bpftool. To sum it up, to
reproduce the issue, all you need is having the "co-re" feature
enabled and a kernel that does not provide all the data structures
expected.
There are changes in bpftool v6.8.0 that assumes the existence of
particular data structures in generated vmlinux.h that is obtained
from the host machine. See [3] for further details. This commit adds
a patch to revert that additional change in v6.8.0.
There's a patch series pending to be submitted upstream [4]. Hopefully,
those will take care of the problem if they land in the next release.
[1] Checking for the clang support
https://github.com/libbpf/bpftool/blob/d4469819d1d639ae2354f3d2ddd10377f081a576/src/Makefile.feature#L12
[2] Using clang to bootstrap
https://github.com/libbpf/bpftool/blob/d4469819d1d639ae2354f3d2ddd10377f081a576/src/Makefile#L175
[3] Question about the problem
https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
[4] Pending patch series
https://lore.kernel.org/bpf/20220421003152.339542-1-alobakin@pm.me/
Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
---
Changelog:
v1: Initial submission
v2: Use a full fledged git patch for bpftool
v3: Fix the snafu that resulted in malformed patch file
v4: Reword the commit message to make it clearer
.../0002-revert-bpf_cookie-change.patch | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 package/bpftool/0002-revert-bpf_cookie-change.patch
diff --git a/package/bpftool/0002-revert-bpf_cookie-change.patch b/package/bpftool/0002-revert-bpf_cookie-change.patch
new file mode 100644
index 0000000000..6f9579bd23
--- /dev/null
+++ b/package/bpftool/0002-revert-bpf_cookie-change.patch
@@ -0,0 +1,129 @@
+From d7c78d1e38cde73c85b491a833f0e6e3f0d62654 Mon Sep 17 00:00:00 2001
+From: Shahab Vahedi <shahab@synopsys.com>
+Date: Tue, 14 Jun 2022 10:12:21 +0200
+Subject: [PATCH] Revert commit "bpftool: Add bpf_cookie to link output"
+
+Building bpftool on a Debian bullseye with clang-11 fails [1].
+This patch reverts the offending commit [2]. If clang-11 is not
+installed, then the "co-re" feature of bpf will not be enabled
+and the issue remains dormant.
+
+[1] Building release 6.8.0 on Debian 11
+https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
+
+[2] bpftool: Add bpf_cookie to link output
+https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=cbdaf71f
+
+Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
+---
+ src/main.h | 2 --
+ src/pids.c | 8 --------
+ src/skeleton/pid_iter.bpf.c | 22 ----------------------
+ src/skeleton/pid_iter.h | 2 --
+ 4 files changed, 34 deletions(-)
+
+diff --git a/src/main.h b/src/main.h
+index aa99ffa..2f2b638 100644
+--- a/src/main.h
++++ b/src/main.h
+@@ -111,9 +111,7 @@ struct obj_ref {
+
+ struct obj_refs {
+ int ref_cnt;
+- bool has_bpf_cookie;
+ struct obj_ref *refs;
+- __u64 bpf_cookie;
+ };
+
+ struct btf;
+diff --git a/src/pids.c b/src/pids.c
+index e2d00d3..57f0d1b 100644
+--- a/src/pids.c
++++ b/src/pids.c
+@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
+ ref->pid = e->pid;
+ memcpy(ref->comm, e->comm, sizeof(ref->comm));
+ refs->ref_cnt = 1;
+- refs->has_bpf_cookie = e->has_bpf_cookie;
+- refs->bpf_cookie = e->bpf_cookie;
+
+ err = hashmap__append(map, u32_as_hash_field(e->id), refs);
+ if (err)
+@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
+-
+ jsonw_name(json_writer, "pids");
+ jsonw_start_array(json_writer);
+ for (i = 0; i < refs->ref_cnt; i++) {
+@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
+ if (refs->ref_cnt == 0)
+ break;
+
+- if (refs->has_bpf_cookie)
+- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
+-
+ printf("%s", prefix);
+ for (i = 0; i < refs->ref_cnt; i++) {
+ struct obj_ref *ref = &refs->refs[i];
+diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
+index eb05ea5..f70702f 100644
+--- a/src/skeleton/pid_iter.bpf.c
++++ b/src/skeleton/pid_iter.bpf.c
+@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
+ }
+ }
+
+-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
+-static __u64 get_bpf_cookie(struct bpf_link *link)
+-{
+- struct bpf_perf_link *perf_link;
+- struct perf_event *event;
+-
+- perf_link = container_of(link, struct bpf_perf_link, link);
+- event = BPF_CORE_READ(perf_link, perf_file, private_data);
+- return BPF_CORE_READ(event, bpf_cookie);
+-}
+-
+ SEC("iter/task_file")
+ int iter(struct bpf_iter__task_file *ctx)
+ {
+@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
+ if (file->f_op != fops)
+ return 0;
+
+- __builtin_memset(&e, 0, sizeof(e));
+ e.pid = task->tgid;
+ e.id = get_obj_id(file->private_data, obj_type);
+-
+- if (obj_type == BPF_OBJ_LINK) {
+- struct bpf_link *link = (struct bpf_link *) file->private_data;
+-
+- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
+- e.has_bpf_cookie = true;
+- e.bpf_cookie = get_bpf_cookie(link);
+- }
+- }
+-
+ bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
+ task->group_leader->comm);
+ bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
+diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
+index bbb570d..5692cf2 100644
+--- a/src/skeleton/pid_iter.h
++++ b/src/skeleton/pid_iter.h
+@@ -6,8 +6,6 @@
+ struct pid_iter_entry {
+ __u32 id;
+ int pid;
+- __u64 bpf_cookie;
+- bool has_bpf_cookie;
+ char comm[16];
+ };
+
+--
+2.30.2
+
--
2.30.2
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-14 17:27 ` Arnout Vandecappelle
@ 2022-06-15 11:03 ` Shahab Vahedi
-1 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi via buildroot @ 2022-06-15 11:03 UTC (permalink / raw)
To: buildroot, Arnout Vandecappelle; +Cc: linux-snps-arc, Shahab Vahedi
On 6/14/22 19:27, Arnout Vandecappelle wrote:
> Actually, the patch didn't appear on patchwork for some reason. It analyzed it as a reply to the previous version of the patch. So you will have to resend it after all.
Done! [1]
[1] patch v4 with reworded commit message
https://patchwork.ozlabs.org/project/buildroot/patch/29d2a8c7-44cd-da42-5fed-f17ec0f8ccf2@synopsys.com/
--
Shahab
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-15 11:03 ` Shahab Vahedi
0 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi @ 2022-06-15 11:03 UTC (permalink / raw)
To: buildroot, Arnout Vandecappelle; +Cc: Shahab Vahedi, linux-snps-arc
On 6/14/22 19:27, Arnout Vandecappelle wrote:
> Actually, the patch didn't appear on patchwork for some reason. It analyzed it as a reply to the previous version of the patch. So you will have to resend it after all.
Done! [1]
[1] patch v4 with reworded commit message
https://patchwork.ozlabs.org/project/buildroot/patch/29d2a8c7-44cd-da42-5fed-f17ec0f8ccf2@synopsys.com/
--
Shahab
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-14 17:14 ` Arnout Vandecappelle
@ 2022-06-15 11:10 ` Shahab Vahedi
-1 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi via buildroot @ 2022-06-15 11:10 UTC (permalink / raw)
To: Arnout Vandecappelle, buildroot; +Cc: linux-snps-arc, Shahab Vahedi
Hi Arnout,
On 6/14/22 19:14, Arnout Vandecappelle wrote:
>
> On 14/06/2022 11:31, Shahab Vahedi wrote:
>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
>
> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
No, I don't do any sort of trickery to build bpftool on my end. The
bootstrapping, if becomes available for your configuration, uses clang
and only clang. I tried to explain this in v4 of the patch [1], the
second paragraph of the commit message.
[1] [v4,1/1] package/bpftool: revert bpf_cookie patch to allow building
https://patchwork.ozlabs.org/project/buildroot/patch/29d2a8c7-44cd-da42-5fed-f17ec0f8ccf2@synopsys.com/
--
Shahab
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-15 11:10 ` Shahab Vahedi
0 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi @ 2022-06-15 11:10 UTC (permalink / raw)
To: Arnout Vandecappelle, buildroot; +Cc: linux-snps-arc, Shahab Vahedi
Hi Arnout,
On 6/14/22 19:14, Arnout Vandecappelle wrote:
>
> On 14/06/2022 11:31, Shahab Vahedi wrote:
>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
>
> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
No, I don't do any sort of trickery to build bpftool on my end. The
bootstrapping, if becomes available for your configuration, uses clang
and only clang. I tried to explain this in v4 of the patch [1], the
second paragraph of the commit message.
[1] [v4,1/1] package/bpftool: revert bpf_cookie patch to allow building
https://patchwork.ozlabs.org/project/buildroot/patch/29d2a8c7-44cd-da42-5fed-f17ec0f8ccf2@synopsys.com/
--
Shahab
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-15 11:10 ` Shahab Vahedi
@ 2022-06-15 23:27 ` James Hilliard
-1 siblings, 0 replies; 43+ messages in thread
From: James Hilliard @ 2022-06-15 23:27 UTC (permalink / raw)
To: Shahab Vahedi; +Cc: linux-snps-arc, buildroot
On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
<buildroot@buildroot.org> wrote:
>
> Hi Arnout,
>
> On 6/14/22 19:14, Arnout Vandecappelle wrote:
> >
> > On 14/06/2022 11:31, Shahab Vahedi wrote:
> >> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
> >
> > How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
>
> No, I don't do any sort of trickery to build bpftool on my end. The
> bootstrapping, if becomes available for your configuration, uses clang
> and only clang. I tried to explain this in v4 of the patch [1], the
> second paragraph of the commit message.
I think clang/llvm support isn't going to work correctly yet since we only have
version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
Minimum clang/llvm version for libbpf co-re is version 10:
https://github.com/libbpf/libbpf#bpf-co-re-compile-once--run-everywhere
>
> [1] [v4,1/1] package/bpftool: revert bpf_cookie patch to allow building
> https://patchwork.ozlabs.org/project/buildroot/patch/29d2a8c7-44cd-da42-5fed-f17ec0f8ccf2@synopsys.com/
>
> --
> Shahab
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-15 23:27 ` James Hilliard
0 siblings, 0 replies; 43+ messages in thread
From: James Hilliard @ 2022-06-15 23:27 UTC (permalink / raw)
To: Shahab Vahedi; +Cc: Arnout Vandecappelle, buildroot, linux-snps-arc
On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
<buildroot@buildroot.org> wrote:
>
> Hi Arnout,
>
> On 6/14/22 19:14, Arnout Vandecappelle wrote:
> >
> > On 14/06/2022 11:31, Shahab Vahedi wrote:
> >> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
> >
> > How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
>
> No, I don't do any sort of trickery to build bpftool on my end. The
> bootstrapping, if becomes available for your configuration, uses clang
> and only clang. I tried to explain this in v4 of the patch [1], the
> second paragraph of the commit message.
I think clang/llvm support isn't going to work correctly yet since we only have
version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
Minimum clang/llvm version for libbpf co-re is version 10:
https://github.com/libbpf/libbpf#bpf-co-re-compile-once--run-everywhere
>
> [1] [v4,1/1] package/bpftool: revert bpf_cookie patch to allow building
> https://patchwork.ozlabs.org/project/buildroot/patch/29d2a8c7-44cd-da42-5fed-f17ec0f8ccf2@synopsys.com/
>
> --
> Shahab
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-15 23:27 ` James Hilliard
@ 2022-06-16 8:11 ` Shahab Vahedi
-1 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi via buildroot @ 2022-06-16 8:11 UTC (permalink / raw)
To: James Hilliard, Shahab Vahedi; +Cc: linux-snps-arc, buildroot
On 6/16/22 01:27, James Hilliard wrote:
> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
> <buildroot@buildroot.org> wrote:
>>
>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
>>>
>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
>>>
>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
>>
>> No, I don't do any sort of trickery to build bpftool on my end. The
>> bootstrapping, if becomes available for your configuration, uses clang
>> and only clang. I tried to explain this in v4 of the patch [1], the
>> second paragraph of the commit message.
>
> I think clang/llvm support isn't going to work correctly yet since we only have
> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
>
> Minimum clang/llvm version for libbpf co-re is version 10:
> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
You're right about the clang version, but it doesn't have anything to do
with Buildroot's clang. The build process uses the clang that is installed
on the host. For Debian bullseye, that is clang 11.
To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
--
Shahab
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-16 8:11 ` Shahab Vahedi
0 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi @ 2022-06-16 8:11 UTC (permalink / raw)
To: James Hilliard, Shahab Vahedi
Cc: Arnout Vandecappelle, buildroot, linux-snps-arc
On 6/16/22 01:27, James Hilliard wrote:
> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
> <buildroot@buildroot.org> wrote:
>>
>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
>>>
>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
>>>
>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
>>
>> No, I don't do any sort of trickery to build bpftool on my end. The
>> bootstrapping, if becomes available for your configuration, uses clang
>> and only clang. I tried to explain this in v4 of the patch [1], the
>> second paragraph of the commit message.
>
> I think clang/llvm support isn't going to work correctly yet since we only have
> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
>
> Minimum clang/llvm version for libbpf co-re is version 10:
> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
You're right about the clang version, but it doesn't have anything to do
with Buildroot's clang. The build process uses the clang that is installed
on the host. For Debian bullseye, that is clang 11.
To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
--
Shahab
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-16 8:11 ` Shahab Vahedi
@ 2022-06-19 15:20 ` Arnout Vandecappelle
-1 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2022-06-19 15:20 UTC (permalink / raw)
To: Shahab Vahedi, James Hilliard; +Cc: linux-snps-arc, buildroot
On 16/06/2022 10:11, Shahab Vahedi wrote:
> On 6/16/22 01:27, James Hilliard wrote:
>> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
>> <buildroot@buildroot.org> wrote:
>>>
>>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
>>>>
>>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
>>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
>>>>
>>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
>>>
>>> No, I don't do any sort of trickery to build bpftool on my end. The
>>> bootstrapping, if becomes available for your configuration, uses clang
>>> and only clang. I tried to explain this in v4 of the patch [1], the
>>> second paragraph of the commit message.
>>
>> I think clang/llvm support isn't going to work correctly yet since we only have
>> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
>> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
>>
>> Minimum clang/llvm version for libbpf co-re is version 10:
>> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
>
> You're right about the clang version, but it doesn't have anything to do
> with Buildroot's clang. The build process uses the clang that is installed
> on the host. For Debian bullseye, that is clang 11.
>
> To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
> the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
Hm, that smells like we actually want to build host-clang (after updating it
to 11.1.0 of course) so that we are sure a known version of clang is used.
Possibly with a check-host-clang check to avoid building it if the installed
clang is good enough.
And we probably want a user-visible option to enable co-re then, because it's
going to be expensive to build.
Regards,
Arnout
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-19 15:20 ` Arnout Vandecappelle
0 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2022-06-19 15:20 UTC (permalink / raw)
To: Shahab Vahedi, James Hilliard; +Cc: buildroot, linux-snps-arc
On 16/06/2022 10:11, Shahab Vahedi wrote:
> On 6/16/22 01:27, James Hilliard wrote:
>> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
>> <buildroot@buildroot.org> wrote:
>>>
>>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
>>>>
>>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
>>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
>>>>
>>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
>>>
>>> No, I don't do any sort of trickery to build bpftool on my end. The
>>> bootstrapping, if becomes available for your configuration, uses clang
>>> and only clang. I tried to explain this in v4 of the patch [1], the
>>> second paragraph of the commit message.
>>
>> I think clang/llvm support isn't going to work correctly yet since we only have
>> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
>> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
>>
>> Minimum clang/llvm version for libbpf co-re is version 10:
>> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
>
> You're right about the clang version, but it doesn't have anything to do
> with Buildroot's clang. The build process uses the clang that is installed
> on the host. For Debian bullseye, that is clang 11.
>
> To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
> the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
Hm, that smells like we actually want to build host-clang (after updating it
to 11.1.0 of course) so that we are sure a known version of clang is used.
Possibly with a check-host-clang check to avoid building it if the installed
clang is good enough.
And we probably want a user-visible option to enable co-re then, because it's
going to be expensive to build.
Regards,
Arnout
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-19 15:20 ` Arnout Vandecappelle
@ 2022-06-19 23:19 ` James Hilliard
-1 siblings, 0 replies; 43+ messages in thread
From: James Hilliard @ 2022-06-19 23:19 UTC (permalink / raw)
To: Arnout Vandecappelle; +Cc: linux-snps-arc, Shahab Vahedi, buildroot
On Sun, Jun 19, 2022 at 9:20 AM Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 16/06/2022 10:11, Shahab Vahedi wrote:
> > On 6/16/22 01:27, James Hilliard wrote:
> >> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
> >> <buildroot@buildroot.org> wrote:
> >>>
> >>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
> >>>>
> >>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
> >>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
> >>>>
> >>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
> >>>
> >>> No, I don't do any sort of trickery to build bpftool on my end. The
> >>> bootstrapping, if becomes available for your configuration, uses clang
> >>> and only clang. I tried to explain this in v4 of the patch [1], the
> >>> second paragraph of the commit message.
> >>
> >> I think clang/llvm support isn't going to work correctly yet since we only have
> >> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
> >> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
> >>
> >> Minimum clang/llvm version for libbpf co-re is version 10:
> >> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
> >
> > You're right about the clang version, but it doesn't have anything to do
> > with Buildroot's clang. The build process uses the clang that is installed
> > on the host. For Debian bullseye, that is clang 11.
> >
> > To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
> > the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
>
>
> Hm, that smells like we actually want to build host-clang (after updating it
> to 11.1.0 of course) so that we are sure a known version of clang is used.
> Possibly with a check-host-clang check to avoid building it if the installed
> clang is good enough.
Dealing with multiple external clang versions may be a bit tricky and difficult
to test properly, we don't really want to use the system clang/llvm although
clang/llvm external toolchain support may be desirable here as those could
be tested by the autobuilders.
It would be good to get clang/llvm updated soon as systemd is now using bpf for
some service security/isolation features that we currently aren't able
to support
due to clang/llvm being too old.
>
> And we probably want a user-visible option to enable co-re then, because it's
> going to be expensive to build.
We may want to make llvm/clang part of the pre-built toolchains
eventually, but for
now I'd say we should just conditionally enable co-re here if we are
already building
a clang/llvm toolchain.
There's some early GCC support for co-re in 12.1 which I was experimenting with
as well which may reduce the need for a llvm/clang toolchain for co-re. The GCC
toolchain BPF support build process is a bit complex however as one needs to
sorta do a hybrid multitarget build with GCC and binutils since GCC
treats BPF as
a separate target(and since GCC along with the binutils GAS assembler
don't natively
handle multi-target toolchain builds themselves).
I have an experimental branch for that here:
https://github.com/buildroot/buildroot/compare/master...jameshilliard:ebpf
I'll try and clean that up a bit once the GCC 12.1 series it is based
on is merged:
https://patchwork.ozlabs.org/project/buildroot/list/?series=302389
>
> Regards,
> Arnout
>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-19 23:19 ` James Hilliard
0 siblings, 0 replies; 43+ messages in thread
From: James Hilliard @ 2022-06-19 23:19 UTC (permalink / raw)
To: Arnout Vandecappelle; +Cc: Shahab Vahedi, buildroot, linux-snps-arc
On Sun, Jun 19, 2022 at 9:20 AM Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 16/06/2022 10:11, Shahab Vahedi wrote:
> > On 6/16/22 01:27, James Hilliard wrote:
> >> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
> >> <buildroot@buildroot.org> wrote:
> >>>
> >>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
> >>>>
> >>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
> >>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
> >>>>
> >>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
> >>>
> >>> No, I don't do any sort of trickery to build bpftool on my end. The
> >>> bootstrapping, if becomes available for your configuration, uses clang
> >>> and only clang. I tried to explain this in v4 of the patch [1], the
> >>> second paragraph of the commit message.
> >>
> >> I think clang/llvm support isn't going to work correctly yet since we only have
> >> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
> >> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
> >>
> >> Minimum clang/llvm version for libbpf co-re is version 10:
> >> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
> >
> > You're right about the clang version, but it doesn't have anything to do
> > with Buildroot's clang. The build process uses the clang that is installed
> > on the host. For Debian bullseye, that is clang 11.
> >
> > To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
> > the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
>
>
> Hm, that smells like we actually want to build host-clang (after updating it
> to 11.1.0 of course) so that we are sure a known version of clang is used.
> Possibly with a check-host-clang check to avoid building it if the installed
> clang is good enough.
Dealing with multiple external clang versions may be a bit tricky and difficult
to test properly, we don't really want to use the system clang/llvm although
clang/llvm external toolchain support may be desirable here as those could
be tested by the autobuilders.
It would be good to get clang/llvm updated soon as systemd is now using bpf for
some service security/isolation features that we currently aren't able
to support
due to clang/llvm being too old.
>
> And we probably want a user-visible option to enable co-re then, because it's
> going to be expensive to build.
We may want to make llvm/clang part of the pre-built toolchains
eventually, but for
now I'd say we should just conditionally enable co-re here if we are
already building
a clang/llvm toolchain.
There's some early GCC support for co-re in 12.1 which I was experimenting with
as well which may reduce the need for a llvm/clang toolchain for co-re. The GCC
toolchain BPF support build process is a bit complex however as one needs to
sorta do a hybrid multitarget build with GCC and binutils since GCC
treats BPF as
a separate target(and since GCC along with the binutils GAS assembler
don't natively
handle multi-target toolchain builds themselves).
I have an experimental branch for that here:
https://github.com/buildroot/buildroot/compare/master...jameshilliard:ebpf
I'll try and clean that up a bit once the GCC 12.1 series it is based
on is merged:
https://patchwork.ozlabs.org/project/buildroot/list/?series=302389
>
> Regards,
> Arnout
>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-19 23:19 ` James Hilliard
@ 2022-06-20 6:45 ` Arnout Vandecappelle
-1 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2022-06-20 6:45 UTC (permalink / raw)
To: James Hilliard; +Cc: linux-snps-arc, Shahab Vahedi, buildroot
On 20/06/2022 01:19, James Hilliard wrote:
> On Sun, Jun 19, 2022 at 9:20 AM Arnout Vandecappelle <arnout@mind.be> wrote:
>>
>>
>>
>> On 16/06/2022 10:11, Shahab Vahedi wrote:
>>> On 6/16/22 01:27, James Hilliard wrote:
>>>> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
>>>> <buildroot@buildroot.org> wrote:
>>>>>
>>>>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
>>>>>>
>>>>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
>>>>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
>>>>>>
>>>>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
>>>>>
>>>>> No, I don't do any sort of trickery to build bpftool on my end. The
>>>>> bootstrapping, if becomes available for your configuration, uses clang
>>>>> and only clang. I tried to explain this in v4 of the patch [1], the
>>>>> second paragraph of the commit message.
>>>>
>>>> I think clang/llvm support isn't going to work correctly yet since we only have
>>>> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
>>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
>>>>
>>>> Minimum clang/llvm version for libbpf co-re is version 10:
>>>> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
>>>
>>> You're right about the clang version, but it doesn't have anything to do
>>> with Buildroot's clang. The build process uses the clang that is installed
>>> on the host. For Debian bullseye, that is clang 11.
>> >
>>> To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
>>> the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
>>
>>
>> Hm, that smells like we actually want to build host-clang (after updating it
>> to 11.1.0 of course) so that we are sure a known version of clang is used.
>> Possibly with a check-host-clang check to avoid building it if the installed
>> clang is good enough.
>
> Dealing with multiple external clang versions may be a bit tricky and difficult
We do it for GCC, so we can do something similar for clang.
> to test properly, we don't really want to use the system clang/llvm although
> clang/llvm external toolchain support may be desirable here as those could
> be tested by the autobuilders.
For GCC, the host toolchain is completely unrelated to the target toolchain.
With clang, it's true that it's possible to use the target compiler for host
builds as well, but don't we still need binutils? So in my mind, there would be
a separate host clang toolchain and target clang toolchain.
> It would be good to get clang/llvm updated soon as systemd is now using bpf for
> some service security/isolation features that we currently aren't able
> to support
> due to clang/llvm being too old.
Unfortunately your series is rather large and has no Reviewed or Acked by
tags... So it tends to languish on patchwork.
>> And we probably want a user-visible option to enable co-re then, because it's
>> going to be expensive to build.
>
> We may want to make llvm/clang part of the pre-built toolchains
> eventually, but for
> now I'd say we should just conditionally enable co-re here if we are
> already building
> a clang/llvm toolchain.
Although I'm usually in favour of automatic dependencies, in this case I'd say
it's worth adding an explicit config option.
> There's some early GCC support for co-re in 12.1 which I was experimenting with
But then it would depend on both host and target GCC >= 12...
> as well which may reduce the need for a llvm/clang toolchain for co-re. The GCC
> toolchain BPF support build process is a bit complex however as one needs to
> sorta do a hybrid multitarget build with GCC and binutils since GCC
> treats BPF as
> a separate target(and since GCC along with the binutils GAS assembler
> don't natively
> handle multi-target toolchain builds themselves).
Ouch, so we still can't reuse the existing host toolchain for the host parts?
then it doesn't help that much, does it?
Regards,
Arnout
>
> I have an experimental branch for that here:
> https://github.com/buildroot/buildroot/compare/master...jameshilliard:ebpf
>
> I'll try and clean that up a bit once the GCC 12.1 series it is based
> on is merged:
> https://patchwork.ozlabs.org/project/buildroot/list/?series=302389
>
>>
>> Regards,
>> Arnout
>>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-20 6:45 ` Arnout Vandecappelle
0 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2022-06-20 6:45 UTC (permalink / raw)
To: James Hilliard; +Cc: Shahab Vahedi, buildroot, linux-snps-arc
On 20/06/2022 01:19, James Hilliard wrote:
> On Sun, Jun 19, 2022 at 9:20 AM Arnout Vandecappelle <arnout@mind.be> wrote:
>>
>>
>>
>> On 16/06/2022 10:11, Shahab Vahedi wrote:
>>> On 6/16/22 01:27, James Hilliard wrote:
>>>> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
>>>> <buildroot@buildroot.org> wrote:
>>>>>
>>>>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
>>>>>>
>>>>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
>>>>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
>>>>>>
>>>>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
>>>>>
>>>>> No, I don't do any sort of trickery to build bpftool on my end. The
>>>>> bootstrapping, if becomes available for your configuration, uses clang
>>>>> and only clang. I tried to explain this in v4 of the patch [1], the
>>>>> second paragraph of the commit message.
>>>>
>>>> I think clang/llvm support isn't going to work correctly yet since we only have
>>>> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
>>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
>>>>
>>>> Minimum clang/llvm version for libbpf co-re is version 10:
>>>> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
>>>
>>> You're right about the clang version, but it doesn't have anything to do
>>> with Buildroot's clang. The build process uses the clang that is installed
>>> on the host. For Debian bullseye, that is clang 11.
>> >
>>> To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
>>> the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
>>
>>
>> Hm, that smells like we actually want to build host-clang (after updating it
>> to 11.1.0 of course) so that we are sure a known version of clang is used.
>> Possibly with a check-host-clang check to avoid building it if the installed
>> clang is good enough.
>
> Dealing with multiple external clang versions may be a bit tricky and difficult
We do it for GCC, so we can do something similar for clang.
> to test properly, we don't really want to use the system clang/llvm although
> clang/llvm external toolchain support may be desirable here as those could
> be tested by the autobuilders.
For GCC, the host toolchain is completely unrelated to the target toolchain.
With clang, it's true that it's possible to use the target compiler for host
builds as well, but don't we still need binutils? So in my mind, there would be
a separate host clang toolchain and target clang toolchain.
> It would be good to get clang/llvm updated soon as systemd is now using bpf for
> some service security/isolation features that we currently aren't able
> to support
> due to clang/llvm being too old.
Unfortunately your series is rather large and has no Reviewed or Acked by
tags... So it tends to languish on patchwork.
>> And we probably want a user-visible option to enable co-re then, because it's
>> going to be expensive to build.
>
> We may want to make llvm/clang part of the pre-built toolchains
> eventually, but for
> now I'd say we should just conditionally enable co-re here if we are
> already building
> a clang/llvm toolchain.
Although I'm usually in favour of automatic dependencies, in this case I'd say
it's worth adding an explicit config option.
> There's some early GCC support for co-re in 12.1 which I was experimenting with
But then it would depend on both host and target GCC >= 12...
> as well which may reduce the need for a llvm/clang toolchain for co-re. The GCC
> toolchain BPF support build process is a bit complex however as one needs to
> sorta do a hybrid multitarget build with GCC and binutils since GCC
> treats BPF as
> a separate target(and since GCC along with the binutils GAS assembler
> don't natively
> handle multi-target toolchain builds themselves).
Ouch, so we still can't reuse the existing host toolchain for the host parts?
then it doesn't help that much, does it?
Regards,
Arnout
>
> I have an experimental branch for that here:
> https://github.com/buildroot/buildroot/compare/master...jameshilliard:ebpf
>
> I'll try and clean that up a bit once the GCC 12.1 series it is based
> on is merged:
> https://patchwork.ozlabs.org/project/buildroot/list/?series=302389
>
>>
>> Regards,
>> Arnout
>>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-20 6:45 ` Arnout Vandecappelle
@ 2022-06-20 9:17 ` James Hilliard
-1 siblings, 0 replies; 43+ messages in thread
From: James Hilliard @ 2022-06-20 9:17 UTC (permalink / raw)
To: Arnout Vandecappelle; +Cc: linux-snps-arc, Shahab Vahedi, buildroot
On Mon, Jun 20, 2022 at 12:45 AM Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 20/06/2022 01:19, James Hilliard wrote:
> > On Sun, Jun 19, 2022 at 9:20 AM Arnout Vandecappelle <arnout@mind.be> wrote:
> >>
> >>
> >>
> >> On 16/06/2022 10:11, Shahab Vahedi wrote:
> >>> On 6/16/22 01:27, James Hilliard wrote:
> >>>> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
> >>>> <buildroot@buildroot.org> wrote:
> >>>>>
> >>>>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
> >>>>>>
> >>>>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
> >>>>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
> >>>>>>
> >>>>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
> >>>>>
> >>>>> No, I don't do any sort of trickery to build bpftool on my end. The
> >>>>> bootstrapping, if becomes available for your configuration, uses clang
> >>>>> and only clang. I tried to explain this in v4 of the patch [1], the
> >>>>> second paragraph of the commit message.
> >>>>
> >>>> I think clang/llvm support isn't going to work correctly yet since we only have
> >>>> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
> >>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
> >>>>
> >>>> Minimum clang/llvm version for libbpf co-re is version 10:
> >>>> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
> >>>
> >>> You're right about the clang version, but it doesn't have anything to do
> >>> with Buildroot's clang. The build process uses the clang that is installed
> >>> on the host. For Debian bullseye, that is clang 11.
> >> >
> >>> To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
> >>> the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
> >>
> >>
> >> Hm, that smells like we actually want to build host-clang (after updating it
> >> to 11.1.0 of course) so that we are sure a known version of clang is used.
> >> Possibly with a check-host-clang check to avoid building it if the installed
> >> clang is good enough.
> >
> > Dealing with multiple external clang versions may be a bit tricky and difficult
>
> We do it for GCC, so we can do something similar for clang.
>
> > to test properly, we don't really want to use the system clang/llvm although
> > clang/llvm external toolchain support may be desirable here as those could
> > be tested by the autobuilders.
>
> For GCC, the host toolchain is completely unrelated to the target toolchain.
> With clang, it's true that it's possible to use the target compiler for host
> builds as well, but don't we still need binutils? So in my mind, there would be
> a separate host clang toolchain and target clang toolchain.
BPF is kinda weird...for both clang and GCC. It's sorta a separate
architecture in
the compiler...but is also sorta not architecture specific in what it
builds for.
>
>
> > It would be good to get clang/llvm updated soon as systemd is now using bpf for
> > some service security/isolation features that we currently aren't able
> > to support
> > due to clang/llvm being too old.
>
> Unfortunately your series is rather large and has no Reviewed or Acked by
> tags... So it tends to languish on patchwork.
The tested-by for the v12 series ended up in the wrong thread I think:
https://lore.kernel.org/buildroot/BN2P110MB16408DC4537E54EF7ECC7906F21A9@BN2P110MB1640.NAMP110.PROD.OUTLOOK.COM/
>
>
> >> And we probably want a user-visible option to enable co-re then, because it's
> >> going to be expensive to build.
> >
> > We may want to make llvm/clang part of the pre-built toolchains
> > eventually, but for
> > now I'd say we should just conditionally enable co-re here if we are
> > already building
> > a clang/llvm toolchain.
>
> Although I'm usually in favour of automatic dependencies, in this case I'd say
> it's worth adding an explicit config option.
>
>
> > There's some early GCC support for co-re in 12.1 which I was experimenting with
>
> But then it would depend on both host and target GCC >= 12...
I thought we don't support GCC on the target.
We would essentially have a 2 architecture cross-toolchain(one real
target arch, and the
BPF virtual architecture compiler/assemblers and such).
>
> > as well which may reduce the need for a llvm/clang toolchain for co-re. The GCC
> > toolchain BPF support build process is a bit complex however as one needs to
> > sorta do a hybrid multitarget build with GCC and binutils since GCC
> > treats BPF as
> > a separate target(and since GCC along with the binutils GAS assembler
> > don't natively
> > handle multi-target toolchain builds themselves).
>
> Ouch, so we still can't reuse the existing host toolchain for the host parts?
> then it doesn't help that much, does it?
We can create a GCC toolchain that can target both BPF and the normal target
architecture...but it's sorta a strange multiarch style toolchain.
>
> Regards,
> Arnout
>
> >
> > I have an experimental branch for that here:
> > https://github.com/buildroot/buildroot/compare/master...jameshilliard:ebpf
> >
> > I'll try and clean that up a bit once the GCC 12.1 series it is based
> > on is merged:
> > https://patchwork.ozlabs.org/project/buildroot/list/?series=302389
> >
> >>
> >> Regards,
> >> Arnout
> >>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-20 9:17 ` James Hilliard
0 siblings, 0 replies; 43+ messages in thread
From: James Hilliard @ 2022-06-20 9:17 UTC (permalink / raw)
To: Arnout Vandecappelle; +Cc: Shahab Vahedi, buildroot, linux-snps-arc
On Mon, Jun 20, 2022 at 12:45 AM Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 20/06/2022 01:19, James Hilliard wrote:
> > On Sun, Jun 19, 2022 at 9:20 AM Arnout Vandecappelle <arnout@mind.be> wrote:
> >>
> >>
> >>
> >> On 16/06/2022 10:11, Shahab Vahedi wrote:
> >>> On 6/16/22 01:27, James Hilliard wrote:
> >>>> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
> >>>> <buildroot@buildroot.org> wrote:
> >>>>>
> >>>>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
> >>>>>>
> >>>>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
> >>>>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
> >>>>>>
> >>>>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
> >>>>>
> >>>>> No, I don't do any sort of trickery to build bpftool on my end. The
> >>>>> bootstrapping, if becomes available for your configuration, uses clang
> >>>>> and only clang. I tried to explain this in v4 of the patch [1], the
> >>>>> second paragraph of the commit message.
> >>>>
> >>>> I think clang/llvm support isn't going to work correctly yet since we only have
> >>>> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
> >>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
> >>>>
> >>>> Minimum clang/llvm version for libbpf co-re is version 10:
> >>>> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
> >>>
> >>> You're right about the clang version, but it doesn't have anything to do
> >>> with Buildroot's clang. The build process uses the clang that is installed
> >>> on the host. For Debian bullseye, that is clang 11.
> >> >
> >>> To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
> >>> the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
> >>
> >>
> >> Hm, that smells like we actually want to build host-clang (after updating it
> >> to 11.1.0 of course) so that we are sure a known version of clang is used.
> >> Possibly with a check-host-clang check to avoid building it if the installed
> >> clang is good enough.
> >
> > Dealing with multiple external clang versions may be a bit tricky and difficult
>
> We do it for GCC, so we can do something similar for clang.
>
> > to test properly, we don't really want to use the system clang/llvm although
> > clang/llvm external toolchain support may be desirable here as those could
> > be tested by the autobuilders.
>
> For GCC, the host toolchain is completely unrelated to the target toolchain.
> With clang, it's true that it's possible to use the target compiler for host
> builds as well, but don't we still need binutils? So in my mind, there would be
> a separate host clang toolchain and target clang toolchain.
BPF is kinda weird...for both clang and GCC. It's sorta a separate
architecture in
the compiler...but is also sorta not architecture specific in what it
builds for.
>
>
> > It would be good to get clang/llvm updated soon as systemd is now using bpf for
> > some service security/isolation features that we currently aren't able
> > to support
> > due to clang/llvm being too old.
>
> Unfortunately your series is rather large and has no Reviewed or Acked by
> tags... So it tends to languish on patchwork.
The tested-by for the v12 series ended up in the wrong thread I think:
https://lore.kernel.org/buildroot/BN2P110MB16408DC4537E54EF7ECC7906F21A9@BN2P110MB1640.NAMP110.PROD.OUTLOOK.COM/
>
>
> >> And we probably want a user-visible option to enable co-re then, because it's
> >> going to be expensive to build.
> >
> > We may want to make llvm/clang part of the pre-built toolchains
> > eventually, but for
> > now I'd say we should just conditionally enable co-re here if we are
> > already building
> > a clang/llvm toolchain.
>
> Although I'm usually in favour of automatic dependencies, in this case I'd say
> it's worth adding an explicit config option.
>
>
> > There's some early GCC support for co-re in 12.1 which I was experimenting with
>
> But then it would depend on both host and target GCC >= 12...
I thought we don't support GCC on the target.
We would essentially have a 2 architecture cross-toolchain(one real
target arch, and the
BPF virtual architecture compiler/assemblers and such).
>
> > as well which may reduce the need for a llvm/clang toolchain for co-re. The GCC
> > toolchain BPF support build process is a bit complex however as one needs to
> > sorta do a hybrid multitarget build with GCC and binutils since GCC
> > treats BPF as
> > a separate target(and since GCC along with the binutils GAS assembler
> > don't natively
> > handle multi-target toolchain builds themselves).
>
> Ouch, so we still can't reuse the existing host toolchain for the host parts?
> then it doesn't help that much, does it?
We can create a GCC toolchain that can target both BPF and the normal target
architecture...but it's sorta a strange multiarch style toolchain.
>
> Regards,
> Arnout
>
> >
> > I have an experimental branch for that here:
> > https://github.com/buildroot/buildroot/compare/master...jameshilliard:ebpf
> >
> > I'll try and clean that up a bit once the GCC 12.1 series it is based
> > on is merged:
> > https://patchwork.ozlabs.org/project/buildroot/list/?series=302389
> >
> >>
> >> Regards,
> >> Arnout
> >>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-20 9:17 ` James Hilliard
@ 2022-06-20 18:27 ` Arnout Vandecappelle
-1 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2022-06-20 18:27 UTC (permalink / raw)
To: James Hilliard; +Cc: linux-snps-arc, Shahab Vahedi, buildroot
On 20/06/2022 11:17, James Hilliard wrote:
> On Mon, Jun 20, 2022 at 12:45 AM Arnout Vandecappelle <arnout@mind.be> wrote:
>>
>>
>>
>> On 20/06/2022 01:19, James Hilliard wrote:
>>> On Sun, Jun 19, 2022 at 9:20 AM Arnout Vandecappelle <arnout@mind.be> wrote:
>>>>
>>>>
>>>>
>>>> On 16/06/2022 10:11, Shahab Vahedi wrote:
>>>>> On 6/16/22 01:27, James Hilliard wrote:
>>>>>> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
>>>>>> <buildroot@buildroot.org> wrote:
>>>>>>>
>>>>>>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
>>>>>>>>
>>>>>>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
>>>>>>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
>>>>>>>>
>>>>>>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
>>>>>>>
>>>>>>> No, I don't do any sort of trickery to build bpftool on my end. The
>>>>>>> bootstrapping, if becomes available for your configuration, uses clang
>>>>>>> and only clang. I tried to explain this in v4 of the patch [1], the
>>>>>>> second paragraph of the commit message.
>>>>>>
>>>>>> I think clang/llvm support isn't going to work correctly yet since we only have
>>>>>> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
>>>>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
>>>>>>
>>>>>> Minimum clang/llvm version for libbpf co-re is version 10:
>>>>>> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
>>>>>
>>>>> You're right about the clang version, but it doesn't have anything to do
>>>>> with Buildroot's clang. The build process uses the clang that is installed
>>>>> on the host. For Debian bullseye, that is clang 11.
>>>> >
>>>>> To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
>>>>> the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
>>>>
>>>>
>>>> Hm, that smells like we actually want to build host-clang (after updating it
>>>> to 11.1.0 of course) so that we are sure a known version of clang is used.
>>>> Possibly with a check-host-clang check to avoid building it if the installed
>>>> clang is good enough.
>>>
>>> Dealing with multiple external clang versions may be a bit tricky and difficult
>>
>> We do it for GCC, so we can do something similar for clang.
>>
>>> to test properly, we don't really want to use the system clang/llvm although
>>> clang/llvm external toolchain support may be desirable here as those could
>>> be tested by the autobuilders.
>>
>> For GCC, the host toolchain is completely unrelated to the target toolchain.
>> With clang, it's true that it's possible to use the target compiler for host
>> builds as well, but don't we still need binutils? So in my mind, there would be
>> a separate host clang toolchain and target clang toolchain.
>
> BPF is kinda weird...for both clang and GCC. It's sorta a separate
> architecture in
> the compiler...but is also sorta not architecture specific in what it
> builds for.
Ah! I understood from Shahab's message that host-clang was used to build a
host tool that is then used to build the target package. But it's actually used
as a cross-compiler then, just with a different target.
>>> It would be good to get clang/llvm updated soon as systemd is now using bpf for
>>> some service security/isolation features that we currently aren't able
>>> to support
>>> due to clang/llvm being too old.
>>
>> Unfortunately your series is rather large and has no Reviewed or Acked by
>> tags... So it tends to languish on patchwork.
>
> The tested-by for the v12 series ended up in the wrong thread I think:
> https://lore.kernel.org/buildroot/BN2P110MB16408DC4537E54EF7ECC7906F21A9@BN2P110MB1640.NAMP110.PROD.OUTLOOK.COM/
All right, I'll look into it!
>>>> And we probably want a user-visible option to enable co-re then, because it's
>>>> going to be expensive to build.
>>>
>>> We may want to make llvm/clang part of the pre-built toolchains
>>> eventually, but for
>>> now I'd say we should just conditionally enable co-re here if we are
>>> already building
>>> a clang/llvm toolchain.
>>
>> Although I'm usually in favour of automatic dependencies, in this case I'd say
>> it's worth adding an explicit config option.
>>
>>
>>> There's some early GCC support for co-re in 12.1 which I was experimenting with
>>
>> But then it would depend on both host and target GCC >= 12...
>
> I thought we don't support GCC on the target.
Yeah, terminology is difficult... With "host gcc" I meant "the gcc that builds
for the host, i.e. the native gcc" and with "target gcc" I meant "the gcc that
builds for the target, i.e. the cross-gcc".
> We would essentially have a 2 architecture cross-toolchain(one real
> target arch, and the
> BPF virtual architecture compiler/assemblers and such).
Yeah, that makes sense... So the idea is that we build GCC with bpf support,
similar like how we build it with Fortran support, right?
Regards,
Arnout
>>> as well which may reduce the need for a llvm/clang toolchain for co-re. The GCC
>>> toolchain BPF support build process is a bit complex however as one needs to
>>> sorta do a hybrid multitarget build with GCC and binutils since GCC
>>> treats BPF as
>>> a separate target(and since GCC along with the binutils GAS assembler
>>> don't natively
>>> handle multi-target toolchain builds themselves).
>>
>> Ouch, so we still can't reuse the existing host toolchain for the host parts?
>> then it doesn't help that much, does it?
>
> We can create a GCC toolchain that can target both BPF and the normal target
> architecture...but it's sorta a strange multiarch style toolchain.
>
>>
>> Regards,
>> Arnout
>>
>>>
>>> I have an experimental branch for that here:
>>> https://github.com/buildroot/buildroot/compare/master...jameshilliard:ebpf
>>>
>>> I'll try and clean that up a bit once the GCC 12.1 series it is based
>>> on is merged:
>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=302389
>>>
>>>>
>>>> Regards,
>>>> Arnout
>>>>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-20 18:27 ` Arnout Vandecappelle
0 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2022-06-20 18:27 UTC (permalink / raw)
To: James Hilliard; +Cc: Shahab Vahedi, buildroot, linux-snps-arc
On 20/06/2022 11:17, James Hilliard wrote:
> On Mon, Jun 20, 2022 at 12:45 AM Arnout Vandecappelle <arnout@mind.be> wrote:
>>
>>
>>
>> On 20/06/2022 01:19, James Hilliard wrote:
>>> On Sun, Jun 19, 2022 at 9:20 AM Arnout Vandecappelle <arnout@mind.be> wrote:
>>>>
>>>>
>>>>
>>>> On 16/06/2022 10:11, Shahab Vahedi wrote:
>>>>> On 6/16/22 01:27, James Hilliard wrote:
>>>>>> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
>>>>>> <buildroot@buildroot.org> wrote:
>>>>>>>
>>>>>>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
>>>>>>>>
>>>>>>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
>>>>>>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
>>>>>>>>
>>>>>>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
>>>>>>>
>>>>>>> No, I don't do any sort of trickery to build bpftool on my end. The
>>>>>>> bootstrapping, if becomes available for your configuration, uses clang
>>>>>>> and only clang. I tried to explain this in v4 of the patch [1], the
>>>>>>> second paragraph of the commit message.
>>>>>>
>>>>>> I think clang/llvm support isn't going to work correctly yet since we only have
>>>>>> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
>>>>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
>>>>>>
>>>>>> Minimum clang/llvm version for libbpf co-re is version 10:
>>>>>> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
>>>>>
>>>>> You're right about the clang version, but it doesn't have anything to do
>>>>> with Buildroot's clang. The build process uses the clang that is installed
>>>>> on the host. For Debian bullseye, that is clang 11.
>>>> >
>>>>> To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
>>>>> the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
>>>>
>>>>
>>>> Hm, that smells like we actually want to build host-clang (after updating it
>>>> to 11.1.0 of course) so that we are sure a known version of clang is used.
>>>> Possibly with a check-host-clang check to avoid building it if the installed
>>>> clang is good enough.
>>>
>>> Dealing with multiple external clang versions may be a bit tricky and difficult
>>
>> We do it for GCC, so we can do something similar for clang.
>>
>>> to test properly, we don't really want to use the system clang/llvm although
>>> clang/llvm external toolchain support may be desirable here as those could
>>> be tested by the autobuilders.
>>
>> For GCC, the host toolchain is completely unrelated to the target toolchain.
>> With clang, it's true that it's possible to use the target compiler for host
>> builds as well, but don't we still need binutils? So in my mind, there would be
>> a separate host clang toolchain and target clang toolchain.
>
> BPF is kinda weird...for both clang and GCC. It's sorta a separate
> architecture in
> the compiler...but is also sorta not architecture specific in what it
> builds for.
Ah! I understood from Shahab's message that host-clang was used to build a
host tool that is then used to build the target package. But it's actually used
as a cross-compiler then, just with a different target.
>>> It would be good to get clang/llvm updated soon as systemd is now using bpf for
>>> some service security/isolation features that we currently aren't able
>>> to support
>>> due to clang/llvm being too old.
>>
>> Unfortunately your series is rather large and has no Reviewed or Acked by
>> tags... So it tends to languish on patchwork.
>
> The tested-by for the v12 series ended up in the wrong thread I think:
> https://lore.kernel.org/buildroot/BN2P110MB16408DC4537E54EF7ECC7906F21A9@BN2P110MB1640.NAMP110.PROD.OUTLOOK.COM/
All right, I'll look into it!
>>>> And we probably want a user-visible option to enable co-re then, because it's
>>>> going to be expensive to build.
>>>
>>> We may want to make llvm/clang part of the pre-built toolchains
>>> eventually, but for
>>> now I'd say we should just conditionally enable co-re here if we are
>>> already building
>>> a clang/llvm toolchain.
>>
>> Although I'm usually in favour of automatic dependencies, in this case I'd say
>> it's worth adding an explicit config option.
>>
>>
>>> There's some early GCC support for co-re in 12.1 which I was experimenting with
>>
>> But then it would depend on both host and target GCC >= 12...
>
> I thought we don't support GCC on the target.
Yeah, terminology is difficult... With "host gcc" I meant "the gcc that builds
for the host, i.e. the native gcc" and with "target gcc" I meant "the gcc that
builds for the target, i.e. the cross-gcc".
> We would essentially have a 2 architecture cross-toolchain(one real
> target arch, and the
> BPF virtual architecture compiler/assemblers and such).
Yeah, that makes sense... So the idea is that we build GCC with bpf support,
similar like how we build it with Fortran support, right?
Regards,
Arnout
>>> as well which may reduce the need for a llvm/clang toolchain for co-re. The GCC
>>> toolchain BPF support build process is a bit complex however as one needs to
>>> sorta do a hybrid multitarget build with GCC and binutils since GCC
>>> treats BPF as
>>> a separate target(and since GCC along with the binutils GAS assembler
>>> don't natively
>>> handle multi-target toolchain builds themselves).
>>
>> Ouch, so we still can't reuse the existing host toolchain for the host parts?
>> then it doesn't help that much, does it?
>
> We can create a GCC toolchain that can target both BPF and the normal target
> architecture...but it's sorta a strange multiarch style toolchain.
>
>>
>> Regards,
>> Arnout
>>
>>>
>>> I have an experimental branch for that here:
>>> https://github.com/buildroot/buildroot/compare/master...jameshilliard:ebpf
>>>
>>> I'll try and clean that up a bit once the GCC 12.1 series it is based
>>> on is merged:
>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=302389
>>>
>>>>
>>>> Regards,
>>>> Arnout
>>>>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-15 10:57 ` Shahab Vahedi
@ 2022-06-24 14:21 ` Shahab Vahedi
-1 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi via buildroot @ 2022-06-24 14:21 UTC (permalink / raw)
To: buildroot; +Cc: linux-snps-arc
ping!
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-06-24 14:21 ` Shahab Vahedi
0 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi @ 2022-06-24 14:21 UTC (permalink / raw)
To: buildroot; +Cc: Arnout Vandecappelle, linux-snps-arc
ping!
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-20 18:27 ` Arnout Vandecappelle
@ 2022-08-09 9:46 ` James Hilliard
-1 siblings, 0 replies; 43+ messages in thread
From: James Hilliard @ 2022-08-09 9:46 UTC (permalink / raw)
To: Arnout Vandecappelle; +Cc: linux-snps-arc, Shahab Vahedi, buildroot
On Mon, Jun 20, 2022 at 12:27 PM Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 20/06/2022 11:17, James Hilliard wrote:
> > On Mon, Jun 20, 2022 at 12:45 AM Arnout Vandecappelle <arnout@mind.be> wrote:
> >>
> >>
> >>
> >> On 20/06/2022 01:19, James Hilliard wrote:
> >>> On Sun, Jun 19, 2022 at 9:20 AM Arnout Vandecappelle <arnout@mind.be> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 16/06/2022 10:11, Shahab Vahedi wrote:
> >>>>> On 6/16/22 01:27, James Hilliard wrote:
> >>>>>> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
> >>>>>> <buildroot@buildroot.org> wrote:
> >>>>>>>
> >>>>>>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
> >>>>>>>>
> >>>>>>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
> >>>>>>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
> >>>>>>>>
> >>>>>>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
> >>>>>>>
> >>>>>>> No, I don't do any sort of trickery to build bpftool on my end. The
> >>>>>>> bootstrapping, if becomes available for your configuration, uses clang
> >>>>>>> and only clang. I tried to explain this in v4 of the patch [1], the
> >>>>>>> second paragraph of the commit message.
> >>>>>>
> >>>>>> I think clang/llvm support isn't going to work correctly yet since we only have
> >>>>>> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
> >>>>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
> >>>>>>
> >>>>>> Minimum clang/llvm version for libbpf co-re is version 10:
> >>>>>> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
> >>>>>
> >>>>> You're right about the clang version, but it doesn't have anything to do
> >>>>> with Buildroot's clang. The build process uses the clang that is installed
> >>>>> on the host. For Debian bullseye, that is clang 11.
> >>>> >
> >>>>> To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
> >>>>> the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
> >>>>
> >>>>
> >>>> Hm, that smells like we actually want to build host-clang (after updating it
> >>>> to 11.1.0 of course) so that we are sure a known version of clang is used.
> >>>> Possibly with a check-host-clang check to avoid building it if the installed
> >>>> clang is good enough.
> >>>
> >>> Dealing with multiple external clang versions may be a bit tricky and difficult
> >>
> >> We do it for GCC, so we can do something similar for clang.
> >>
> >>> to test properly, we don't really want to use the system clang/llvm although
> >>> clang/llvm external toolchain support may be desirable here as those could
> >>> be tested by the autobuilders.
> >>
> >> For GCC, the host toolchain is completely unrelated to the target toolchain.
> >> With clang, it's true that it's possible to use the target compiler for host
> >> builds as well, but don't we still need binutils? So in my mind, there would be
> >> a separate host clang toolchain and target clang toolchain.
> >
> > BPF is kinda weird...for both clang and GCC. It's sorta a separate
> > architecture in
> > the compiler...but is also sorta not architecture specific in what it
> > builds for.
>
> Ah! I understood from Shahab's message that host-clang was used to build a
> host tool that is then used to build the target package. But it's actually used
> as a cross-compiler then, just with a different target.
>
>
> >>> It would be good to get clang/llvm updated soon as systemd is now using bpf for
> >>> some service security/isolation features that we currently aren't able
> >>> to support
> >>> due to clang/llvm being too old.
> >>
> >> Unfortunately your series is rather large and has no Reviewed or Acked by
> >> tags... So it tends to languish on patchwork.
> >
> > The tested-by for the v12 series ended up in the wrong thread I think:
> > https://lore.kernel.org/buildroot/BN2P110MB16408DC4537E54EF7ECC7906F21A9@BN2P110MB1640.NAMP110.PROD.OUTLOOK.COM/
>
> All right, I'll look into it!
>
>
> >>>> And we probably want a user-visible option to enable co-re then, because it's
> >>>> going to be expensive to build.
> >>>
> >>> We may want to make llvm/clang part of the pre-built toolchains
> >>> eventually, but for
> >>> now I'd say we should just conditionally enable co-re here if we are
> >>> already building
> >>> a clang/llvm toolchain.
> >>
> >> Although I'm usually in favour of automatic dependencies, in this case I'd say
> >> it's worth adding an explicit config option.
> >>
> >>
> >>> There's some early GCC support for co-re in 12.1 which I was experimenting with
> >>
> >> But then it would depend on both host and target GCC >= 12...
> >
> > I thought we don't support GCC on the target.
>
> Yeah, terminology is difficult... With "host gcc" I meant "the gcc that builds
> for the host, i.e. the native gcc" and with "target gcc" I meant "the gcc that
> builds for the target, i.e. the cross-gcc".
>
> > We would essentially have a 2 architecture cross-toolchain(one real
> > target arch, and the
> > BPF virtual architecture compiler/assemblers and such).
>
>
> Yeah, that makes sense... So the idea is that we build GCC with bpf support,
> similar like how we build it with Fortran support, right?
Well it's a bit different in how we build the toolchain, but it's more
or less used like
a separate language when building packages that need BPF.
I sent an initial series adding BPF support:
https://lore.kernel.org/buildroot/20220809094109.2279598-1-james.hilliard1@gmail.com/
>
>
> Regards,
> Arnout
>
> >>> as well which may reduce the need for a llvm/clang toolchain for co-re. The GCC
> >>> toolchain BPF support build process is a bit complex however as one needs to
> >>> sorta do a hybrid multitarget build with GCC and binutils since GCC
> >>> treats BPF as
> >>> a separate target(and since GCC along with the binutils GAS assembler
> >>> don't natively
> >>> handle multi-target toolchain builds themselves).
> >>
> >> Ouch, so we still can't reuse the existing host toolchain for the host parts?
> >> then it doesn't help that much, does it?
> >
> > We can create a GCC toolchain that can target both BPF and the normal target
> > architecture...but it's sorta a strange multiarch style toolchain.
> >
> >>
> >> Regards,
> >> Arnout
> >>
> >>>
> >>> I have an experimental branch for that here:
> >>> https://github.com/buildroot/buildroot/compare/master...jameshilliard:ebpf
> >>>
> >>> I'll try and clean that up a bit once the GCC 12.1 series it is based
> >>> on is merged:
> >>> https://patchwork.ozlabs.org/project/buildroot/list/?series=302389
> >>>
> >>>>
> >>>> Regards,
> >>>> Arnout
> >>>>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v3 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2022-08-09 9:46 ` James Hilliard
0 siblings, 0 replies; 43+ messages in thread
From: James Hilliard @ 2022-08-09 9:46 UTC (permalink / raw)
To: Arnout Vandecappelle; +Cc: Shahab Vahedi, buildroot, linux-snps-arc
On Mon, Jun 20, 2022 at 12:27 PM Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 20/06/2022 11:17, James Hilliard wrote:
> > On Mon, Jun 20, 2022 at 12:45 AM Arnout Vandecappelle <arnout@mind.be> wrote:
> >>
> >>
> >>
> >> On 20/06/2022 01:19, James Hilliard wrote:
> >>> On Sun, Jun 19, 2022 at 9:20 AM Arnout Vandecappelle <arnout@mind.be> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 16/06/2022 10:11, Shahab Vahedi wrote:
> >>>>> On 6/16/22 01:27, James Hilliard wrote:
> >>>>>> On Wed, Jun 15, 2022 at 5:10 AM Shahab Vahedi via buildroot
> >>>>>> <buildroot@buildroot.org> wrote:
> >>>>>>>
> >>>>>>> On 6/14/22 19:14, Arnout Vandecappelle wrote:
> >>>>>>>>
> >>>>>>>> On 14/06/2022 11:31, Shahab Vahedi wrote:
> >>>>>>>>> Building bpftool on Debian 11 (bullseye) with kernel v5.10 and clang-11
> >>>>>>>>
> >>>>>>>> How do you build host-bpftool with clang in Buildroot context? HOSTCC is set to gcc in the Makefile... Do you supply an explicit HOSTCC= on the Buildroot command line? I'm not sure if we are really interested in carrying fixes for such exotic and not-really-supported situations...
> >>>>>>>
> >>>>>>> No, I don't do any sort of trickery to build bpftool on my end. The
> >>>>>>> bootstrapping, if becomes available for your configuration, uses clang
> >>>>>>> and only clang. I tried to explain this in v4 of the patch [1], the
> >>>>>>> second paragraph of the commit message.
> >>>>>>
> >>>>>> I think clang/llvm support isn't going to work correctly yet since we only have
> >>>>>> version 9.0.1, there's a series bumping to version 11.1.0 that should fix that:
> >>>>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=291585
> >>>>>>
> >>>>>> Minimum clang/llvm version for libbpf co-re is version 10:
> >>>>>> https://github.com/libbpf/libbpf*bpf-co-re-compile-once--run-everywhere
> >>>>>
> >>>>> You're right about the clang version, but it doesn't have anything to do
> >>>>> with Buildroot's clang. The build process uses the clang that is installed
> >>>>> on the host. For Debian bullseye, that is clang 11.
> >>>> >
> >>>>> To emphasise, I am cross-building bpftool for my "arc-linux" target, and yet
> >>>>> the bootstrap part of bpftool, uses the x86 clang of the Debian machine.
> >>>>
> >>>>
> >>>> Hm, that smells like we actually want to build host-clang (after updating it
> >>>> to 11.1.0 of course) so that we are sure a known version of clang is used.
> >>>> Possibly with a check-host-clang check to avoid building it if the installed
> >>>> clang is good enough.
> >>>
> >>> Dealing with multiple external clang versions may be a bit tricky and difficult
> >>
> >> We do it for GCC, so we can do something similar for clang.
> >>
> >>> to test properly, we don't really want to use the system clang/llvm although
> >>> clang/llvm external toolchain support may be desirable here as those could
> >>> be tested by the autobuilders.
> >>
> >> For GCC, the host toolchain is completely unrelated to the target toolchain.
> >> With clang, it's true that it's possible to use the target compiler for host
> >> builds as well, but don't we still need binutils? So in my mind, there would be
> >> a separate host clang toolchain and target clang toolchain.
> >
> > BPF is kinda weird...for both clang and GCC. It's sorta a separate
> > architecture in
> > the compiler...but is also sorta not architecture specific in what it
> > builds for.
>
> Ah! I understood from Shahab's message that host-clang was used to build a
> host tool that is then used to build the target package. But it's actually used
> as a cross-compiler then, just with a different target.
>
>
> >>> It would be good to get clang/llvm updated soon as systemd is now using bpf for
> >>> some service security/isolation features that we currently aren't able
> >>> to support
> >>> due to clang/llvm being too old.
> >>
> >> Unfortunately your series is rather large and has no Reviewed or Acked by
> >> tags... So it tends to languish on patchwork.
> >
> > The tested-by for the v12 series ended up in the wrong thread I think:
> > https://lore.kernel.org/buildroot/BN2P110MB16408DC4537E54EF7ECC7906F21A9@BN2P110MB1640.NAMP110.PROD.OUTLOOK.COM/
>
> All right, I'll look into it!
>
>
> >>>> And we probably want a user-visible option to enable co-re then, because it's
> >>>> going to be expensive to build.
> >>>
> >>> We may want to make llvm/clang part of the pre-built toolchains
> >>> eventually, but for
> >>> now I'd say we should just conditionally enable co-re here if we are
> >>> already building
> >>> a clang/llvm toolchain.
> >>
> >> Although I'm usually in favour of automatic dependencies, in this case I'd say
> >> it's worth adding an explicit config option.
> >>
> >>
> >>> There's some early GCC support for co-re in 12.1 which I was experimenting with
> >>
> >> But then it would depend on both host and target GCC >= 12...
> >
> > I thought we don't support GCC on the target.
>
> Yeah, terminology is difficult... With "host gcc" I meant "the gcc that builds
> for the host, i.e. the native gcc" and with "target gcc" I meant "the gcc that
> builds for the target, i.e. the cross-gcc".
>
> > We would essentially have a 2 architecture cross-toolchain(one real
> > target arch, and the
> > BPF virtual architecture compiler/assemblers and such).
>
>
> Yeah, that makes sense... So the idea is that we build GCC with bpf support,
> similar like how we build it with Fortran support, right?
Well it's a bit different in how we build the toolchain, but it's more
or less used like
a separate language when building packages that need BPF.
I sent an initial series adding BPF support:
https://lore.kernel.org/buildroot/20220809094109.2279598-1-james.hilliard1@gmail.com/
>
>
> Regards,
> Arnout
>
> >>> as well which may reduce the need for a llvm/clang toolchain for co-re. The GCC
> >>> toolchain BPF support build process is a bit complex however as one needs to
> >>> sorta do a hybrid multitarget build with GCC and binutils since GCC
> >>> treats BPF as
> >>> a separate target(and since GCC along with the binutils GAS assembler
> >>> don't natively
> >>> handle multi-target toolchain builds themselves).
> >>
> >> Ouch, so we still can't reuse the existing host toolchain for the host parts?
> >> then it doesn't help that much, does it?
> >
> > We can create a GCC toolchain that can target both BPF and the normal target
> > architecture...but it's sorta a strange multiarch style toolchain.
> >
> >>
> >> Regards,
> >> Arnout
> >>
> >>>
> >>> I have an experimental branch for that here:
> >>> https://github.com/buildroot/buildroot/compare/master...jameshilliard:ebpf
> >>>
> >>> I'll try and clean that up a bit once the GCC 12.1 series it is based
> >>> on is merged:
> >>> https://patchwork.ozlabs.org/project/buildroot/list/?series=302389
> >>>
> >>>>
> >>>> Regards,
> >>>> Arnout
> >>>>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
2022-06-15 10:57 ` Shahab Vahedi
@ 2023-02-08 16:36 ` Arnout Vandecappelle
-1 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2023-02-08 16:36 UTC (permalink / raw)
To: Shahab Vahedi, buildroot; +Cc: linux-snps-arc
Hi Shahab,
On 15/06/2022 12:57, Shahab Vahedi wrote:
> Building bpftool on Debian 11 (bullseye) with kernel v5.10 fails:
>
> -----------------------------------8<-----------------------------------
> $ make
> .
> .
> .
> CLANG pid_iter.bpf.o
> skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type
> 'struct bpf_perf_link'
> perf_link = container_of(link, struct bpf_perf_link, link);
> .
> .
> .
> skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in
> 'struct perf_event'
> return BPF_CORE_READ(event, bpf_cookie);
> .
> .
> .
> 10 errors generated.
> make: *** [Makefile:176: pid_iter.bpf.o] Error 1
> ----------------------------------->8-----------------------------------
>
> To be clearer about the setup, there is a clang (11) installed on this
> system. bpftool's build process enables "co-re" feature (Compile-Once,
> Run-Everywhere) if the clang compiler is new enough to support
> BTF_KIND_VAR [1]. When that happens, bpftool will bootstrap itself:
> build/bootstrap/libbpf.a. This bootstrap part is about those *.bpf.c
> programs and are only built by invoking clang [2], irrespective of the
> compiler used to build the rest of the bpftool. To sum it up, to
> reproduce the issue, all you need is having the "co-re" feature
> enabled and a kernel that does not provide all the data structures
> expected.
>
> There are changes in bpftool v6.8.0 that assumes the existence of
> particular data structures in generated vmlinux.h that is obtained
> from the host machine. See [3] for further details. This commit adds
> a patch to revert that additional change in v6.8.0.
>
> There's a patch series pending to be submitted upstream [4]. Hopefully,
> those will take care of the problem if they land in the next release.
Unfortunately, bpftool has been bumped two times since then and it looks like
those patches are still not included...
>
> [1] Checking for the clang support
> https://github.com/libbpf/bpftool/blob/d4469819d1d639ae2354f3d2ddd10377f081a576/src/Makefile.feature#L12
>
> [2] Using clang to bootstrap
> https://github.com/libbpf/bpftool/blob/d4469819d1d639ae2354f3d2ddd10377f081a576/src/Makefile#L175
>
> [3] Question about the problem
> https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
>
> [4] Pending patch series
> https://lore.kernel.org/bpf/20220421003152.339542-1-alobakin@pm.me/
It's not clear to me why you did a revert of the cookie feature rather than
using those patches. I think the first two or three should be sufficient to fix
your issue?
For the time being, I marked this as Changes Requested. If the upstream
patches are not sufficient, please send a mail upstream (as a reply to that
series) explaining the problem (again), and re-send this patch to Buildroot. If
it does fix things, please send a mail upstream to ask to move the series
forward (explaining the issue you have), and send a patch to Buildroot that adds
the needed patches.
Thanks!
Regards,
Arnout
>
> Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
> ---
>
> Changelog:
> v1: Initial submission
> v2: Use a full fledged git patch for bpftool
> v3: Fix the snafu that resulted in malformed patch file
> v4: Reword the commit message to make it clearer
>
> .../0002-revert-bpf_cookie-change.patch | 129 ++++++++++++++++++
> 1 file changed, 129 insertions(+)
> create mode 100644 package/bpftool/0002-revert-bpf_cookie-change.patch
>
> diff --git a/package/bpftool/0002-revert-bpf_cookie-change.patch b/package/bpftool/0002-revert-bpf_cookie-change.patch
> new file mode 100644
> index 0000000000..6f9579bd23
> --- /dev/null
> +++ b/package/bpftool/0002-revert-bpf_cookie-change.patch
> @@ -0,0 +1,129 @@
> +From d7c78d1e38cde73c85b491a833f0e6e3f0d62654 Mon Sep 17 00:00:00 2001
> +From: Shahab Vahedi <shahab@synopsys.com>
> +Date: Tue, 14 Jun 2022 10:12:21 +0200
> +Subject: [PATCH] Revert commit "bpftool: Add bpf_cookie to link output"
> +
> +Building bpftool on a Debian bullseye with clang-11 fails [1].
> +This patch reverts the offending commit [2]. If clang-11 is not
> +installed, then the "co-re" feature of bpf will not be enabled
> +and the issue remains dormant.
> +
> +[1] Building release 6.8.0 on Debian 11
> +https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
> +
> +[2] bpftool: Add bpf_cookie to link output
> +https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=cbdaf71f
> +
> +Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
> +---
> + src/main.h | 2 --
> + src/pids.c | 8 --------
> + src/skeleton/pid_iter.bpf.c | 22 ----------------------
> + src/skeleton/pid_iter.h | 2 --
> + 4 files changed, 34 deletions(-)
> +
> +diff --git a/src/main.h b/src/main.h
> +index aa99ffa..2f2b638 100644
> +--- a/src/main.h
> ++++ b/src/main.h
> +@@ -111,9 +111,7 @@ struct obj_ref {
> +
> + struct obj_refs {
> + int ref_cnt;
> +- bool has_bpf_cookie;
> + struct obj_ref *refs;
> +- __u64 bpf_cookie;
> + };
> +
> + struct btf;
> +diff --git a/src/pids.c b/src/pids.c
> +index e2d00d3..57f0d1b 100644
> +--- a/src/pids.c
> ++++ b/src/pids.c
> +@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
> + ref->pid = e->pid;
> + memcpy(ref->comm, e->comm, sizeof(ref->comm));
> + refs->ref_cnt = 1;
> +- refs->has_bpf_cookie = e->has_bpf_cookie;
> +- refs->bpf_cookie = e->bpf_cookie;
> +
> + err = hashmap__append(map, u32_as_hash_field(e->id), refs);
> + if (err)
> +@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
> + if (refs->ref_cnt == 0)
> + break;
> +
> +- if (refs->has_bpf_cookie)
> +- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
> +-
> + jsonw_name(json_writer, "pids");
> + jsonw_start_array(json_writer);
> + for (i = 0; i < refs->ref_cnt; i++) {
> +@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
> + if (refs->ref_cnt == 0)
> + break;
> +
> +- if (refs->has_bpf_cookie)
> +- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
> +-
> + printf("%s", prefix);
> + for (i = 0; i < refs->ref_cnt; i++) {
> + struct obj_ref *ref = &refs->refs[i];
> +diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
> +index eb05ea5..f70702f 100644
> +--- a/src/skeleton/pid_iter.bpf.c
> ++++ b/src/skeleton/pid_iter.bpf.c
> +@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
> + }
> + }
> +
> +-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
> +-static __u64 get_bpf_cookie(struct bpf_link *link)
> +-{
> +- struct bpf_perf_link *perf_link;
> +- struct perf_event *event;
> +-
> +- perf_link = container_of(link, struct bpf_perf_link, link);
> +- event = BPF_CORE_READ(perf_link, perf_file, private_data);
> +- return BPF_CORE_READ(event, bpf_cookie);
> +-}
> +-
> + SEC("iter/task_file")
> + int iter(struct bpf_iter__task_file *ctx)
> + {
> +@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
> + if (file->f_op != fops)
> + return 0;
> +
> +- __builtin_memset(&e, 0, sizeof(e));
> + e.pid = task->tgid;
> + e.id = get_obj_id(file->private_data, obj_type);
> +-
> +- if (obj_type == BPF_OBJ_LINK) {
> +- struct bpf_link *link = (struct bpf_link *) file->private_data;
> +-
> +- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
> +- e.has_bpf_cookie = true;
> +- e.bpf_cookie = get_bpf_cookie(link);
> +- }
> +- }
> +-
> + bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
> + task->group_leader->comm);
> + bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
> +diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
> +index bbb570d..5692cf2 100644
> +--- a/src/skeleton/pid_iter.h
> ++++ b/src/skeleton/pid_iter.h
> +@@ -6,8 +6,6 @@
> + struct pid_iter_entry {
> + __u32 id;
> + int pid;
> +- __u64 bpf_cookie;
> +- bool has_bpf_cookie;
> + char comm[16];
> + };
> +
> +--
> +2.30.2
> +
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2023-02-08 16:36 ` Arnout Vandecappelle
0 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2023-02-08 16:36 UTC (permalink / raw)
To: Shahab Vahedi, buildroot; +Cc: linux-snps-arc
Hi Shahab,
On 15/06/2022 12:57, Shahab Vahedi wrote:
> Building bpftool on Debian 11 (bullseye) with kernel v5.10 fails:
>
> -----------------------------------8<-----------------------------------
> $ make
> .
> .
> .
> CLANG pid_iter.bpf.o
> skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type
> 'struct bpf_perf_link'
> perf_link = container_of(link, struct bpf_perf_link, link);
> .
> .
> .
> skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in
> 'struct perf_event'
> return BPF_CORE_READ(event, bpf_cookie);
> .
> .
> .
> 10 errors generated.
> make: *** [Makefile:176: pid_iter.bpf.o] Error 1
> ----------------------------------->8-----------------------------------
>
> To be clearer about the setup, there is a clang (11) installed on this
> system. bpftool's build process enables "co-re" feature (Compile-Once,
> Run-Everywhere) if the clang compiler is new enough to support
> BTF_KIND_VAR [1]. When that happens, bpftool will bootstrap itself:
> build/bootstrap/libbpf.a. This bootstrap part is about those *.bpf.c
> programs and are only built by invoking clang [2], irrespective of the
> compiler used to build the rest of the bpftool. To sum it up, to
> reproduce the issue, all you need is having the "co-re" feature
> enabled and a kernel that does not provide all the data structures
> expected.
>
> There are changes in bpftool v6.8.0 that assumes the existence of
> particular data structures in generated vmlinux.h that is obtained
> from the host machine. See [3] for further details. This commit adds
> a patch to revert that additional change in v6.8.0.
>
> There's a patch series pending to be submitted upstream [4]. Hopefully,
> those will take care of the problem if they land in the next release.
Unfortunately, bpftool has been bumped two times since then and it looks like
those patches are still not included...
>
> [1] Checking for the clang support
> https://github.com/libbpf/bpftool/blob/d4469819d1d639ae2354f3d2ddd10377f081a576/src/Makefile.feature#L12
>
> [2] Using clang to bootstrap
> https://github.com/libbpf/bpftool/blob/d4469819d1d639ae2354f3d2ddd10377f081a576/src/Makefile#L175
>
> [3] Question about the problem
> https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
>
> [4] Pending patch series
> https://lore.kernel.org/bpf/20220421003152.339542-1-alobakin@pm.me/
It's not clear to me why you did a revert of the cookie feature rather than
using those patches. I think the first two or three should be sufficient to fix
your issue?
For the time being, I marked this as Changes Requested. If the upstream
patches are not sufficient, please send a mail upstream (as a reply to that
series) explaining the problem (again), and re-send this patch to Buildroot. If
it does fix things, please send a mail upstream to ask to move the series
forward (explaining the issue you have), and send a patch to Buildroot that adds
the needed patches.
Thanks!
Regards,
Arnout
>
> Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
> ---
>
> Changelog:
> v1: Initial submission
> v2: Use a full fledged git patch for bpftool
> v3: Fix the snafu that resulted in malformed patch file
> v4: Reword the commit message to make it clearer
>
> .../0002-revert-bpf_cookie-change.patch | 129 ++++++++++++++++++
> 1 file changed, 129 insertions(+)
> create mode 100644 package/bpftool/0002-revert-bpf_cookie-change.patch
>
> diff --git a/package/bpftool/0002-revert-bpf_cookie-change.patch b/package/bpftool/0002-revert-bpf_cookie-change.patch
> new file mode 100644
> index 0000000000..6f9579bd23
> --- /dev/null
> +++ b/package/bpftool/0002-revert-bpf_cookie-change.patch
> @@ -0,0 +1,129 @@
> +From d7c78d1e38cde73c85b491a833f0e6e3f0d62654 Mon Sep 17 00:00:00 2001
> +From: Shahab Vahedi <shahab@synopsys.com>
> +Date: Tue, 14 Jun 2022 10:12:21 +0200
> +Subject: [PATCH] Revert commit "bpftool: Add bpf_cookie to link output"
> +
> +Building bpftool on a Debian bullseye with clang-11 fails [1].
> +This patch reverts the offending commit [2]. If clang-11 is not
> +installed, then the "co-re" feature of bpf will not be enabled
> +and the issue remains dormant.
> +
> +[1] Building release 6.8.0 on Debian 11
> +https://lore.kernel.org/bpf/c47f732d-dba8-2c13-7c72-3a651bf72353@synopsys.com/t/#u
> +
> +[2] bpftool: Add bpf_cookie to link output
> +https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=cbdaf71f
> +
> +Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
> +---
> + src/main.h | 2 --
> + src/pids.c | 8 --------
> + src/skeleton/pid_iter.bpf.c | 22 ----------------------
> + src/skeleton/pid_iter.h | 2 --
> + 4 files changed, 34 deletions(-)
> +
> +diff --git a/src/main.h b/src/main.h
> +index aa99ffa..2f2b638 100644
> +--- a/src/main.h
> ++++ b/src/main.h
> +@@ -111,9 +111,7 @@ struct obj_ref {
> +
> + struct obj_refs {
> + int ref_cnt;
> +- bool has_bpf_cookie;
> + struct obj_ref *refs;
> +- __u64 bpf_cookie;
> + };
> +
> + struct btf;
> +diff --git a/src/pids.c b/src/pids.c
> +index e2d00d3..57f0d1b 100644
> +--- a/src/pids.c
> ++++ b/src/pids.c
> +@@ -78,8 +78,6 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
> + ref->pid = e->pid;
> + memcpy(ref->comm, e->comm, sizeof(ref->comm));
> + refs->ref_cnt = 1;
> +- refs->has_bpf_cookie = e->has_bpf_cookie;
> +- refs->bpf_cookie = e->bpf_cookie;
> +
> + err = hashmap__append(map, u32_as_hash_field(e->id), refs);
> + if (err)
> +@@ -206,9 +204,6 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
> + if (refs->ref_cnt == 0)
> + break;
> +
> +- if (refs->has_bpf_cookie)
> +- jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
> +-
> + jsonw_name(json_writer, "pids");
> + jsonw_start_array(json_writer);
> + for (i = 0; i < refs->ref_cnt; i++) {
> +@@ -238,9 +233,6 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
> + if (refs->ref_cnt == 0)
> + break;
> +
> +- if (refs->has_bpf_cookie)
> +- printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
> +-
> + printf("%s", prefix);
> + for (i = 0; i < refs->ref_cnt; i++) {
> + struct obj_ref *ref = &refs->refs[i];
> +diff --git a/src/skeleton/pid_iter.bpf.c b/src/skeleton/pid_iter.bpf.c
> +index eb05ea5..f70702f 100644
> +--- a/src/skeleton/pid_iter.bpf.c
> ++++ b/src/skeleton/pid_iter.bpf.c
> +@@ -38,17 +38,6 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
> + }
> + }
> +
> +-/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
> +-static __u64 get_bpf_cookie(struct bpf_link *link)
> +-{
> +- struct bpf_perf_link *perf_link;
> +- struct perf_event *event;
> +-
> +- perf_link = container_of(link, struct bpf_perf_link, link);
> +- event = BPF_CORE_READ(perf_link, perf_file, private_data);
> +- return BPF_CORE_READ(event, bpf_cookie);
> +-}
> +-
> + SEC("iter/task_file")
> + int iter(struct bpf_iter__task_file *ctx)
> + {
> +@@ -80,19 +69,8 @@ int iter(struct bpf_iter__task_file *ctx)
> + if (file->f_op != fops)
> + return 0;
> +
> +- __builtin_memset(&e, 0, sizeof(e));
> + e.pid = task->tgid;
> + e.id = get_obj_id(file->private_data, obj_type);
> +-
> +- if (obj_type == BPF_OBJ_LINK) {
> +- struct bpf_link *link = (struct bpf_link *) file->private_data;
> +-
> +- if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
> +- e.has_bpf_cookie = true;
> +- e.bpf_cookie = get_bpf_cookie(link);
> +- }
> +- }
> +-
> + bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
> + task->group_leader->comm);
> + bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
> +diff --git a/src/skeleton/pid_iter.h b/src/skeleton/pid_iter.h
> +index bbb570d..5692cf2 100644
> +--- a/src/skeleton/pid_iter.h
> ++++ b/src/skeleton/pid_iter.h
> +@@ -6,8 +6,6 @@
> + struct pid_iter_entry {
> + __u32 id;
> + int pid;
> +- __u64 bpf_cookie;
> +- bool has_bpf_cookie;
> + char comm[16];
> + };
> +
> +--
> +2.30.2
> +
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
2023-02-08 16:36 ` Arnout Vandecappelle
@ 2023-02-09 12:23 ` Shahab Vahedi via buildroot
-1 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi @ 2023-02-09 12:23 UTC (permalink / raw)
To: Arnout Vandecappelle
Cc: buildroot, linux-snps-arc, Alexey Brodkin, Shahab Vahedi
Hi Arnout,
On 2/8/23 17:36, Arnout Vandecappelle wrote:
>
> It's not clear to me why you did a revert of the cookie feature rather than
> using those patches. I think the first two or three should be sufficient to
> fix your issue?
Ideally, the correct way would be applying that pending series. But since
there were comments that some of the patches might need reworking [1], I did
not feel confident to add them. Therefore, I tried to keep my solution minimal
and solve it by eliminating the problem. I know, it is not appealing.
> For the time being, I marked this as Changes Requested. If the upstream
> patches are not sufficient, please send a mail upstream (as a reply to that
> series) explaining the problem (again), and re-send this patch to
> Buildroot. If it does fix things, please send a mail upstream to ask to
> move the series forward (explaining the issue you have), and send a patch
> to Buildroot that adds the needed patches.
They (re)confirmed the issue to me in the past [2] and are aware that its
solution is missing from all the releases onward (see the first point of
"Known bugs" in the release page [3]).
[1]
https://lore.kernel.org/bpf/20220421003152.339542-3-alobakin@pm.me/T/#rb9ce86e9f25b2d097b88d87af8ffdfa401d63c68
[2]
https://lore.kernel.org/bpf/b1a604e1-be09-ac0b-ff22-b194ae9ce886@isovalent.com/
[3]
https://github.com/libbpf/bpftool/releases
--
Shahab
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2023-02-09 12:23 ` Shahab Vahedi via buildroot
0 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi via buildroot @ 2023-02-09 12:23 UTC (permalink / raw)
To: Arnout Vandecappelle
Cc: linux-snps-arc, Alexey Brodkin, Shahab Vahedi, buildroot
Hi Arnout,
On 2/8/23 17:36, Arnout Vandecappelle wrote:
>
> It's not clear to me why you did a revert of the cookie feature rather than
> using those patches. I think the first two or three should be sufficient to
> fix your issue?
Ideally, the correct way would be applying that pending series. But since
there were comments that some of the patches might need reworking [1], I did
not feel confident to add them. Therefore, I tried to keep my solution minimal
and solve it by eliminating the problem. I know, it is not appealing.
> For the time being, I marked this as Changes Requested. If the upstream
> patches are not sufficient, please send a mail upstream (as a reply to that
> series) explaining the problem (again), and re-send this patch to
> Buildroot. If it does fix things, please send a mail upstream to ask to
> move the series forward (explaining the issue you have), and send a patch
> to Buildroot that adds the needed patches.
They (re)confirmed the issue to me in the past [2] and are aware that its
solution is missing from all the releases onward (see the first point of
"Known bugs" in the release page [3]).
[1]
https://lore.kernel.org/bpf/20220421003152.339542-3-alobakin@pm.me/T/#rb9ce86e9f25b2d097b88d87af8ffdfa401d63c68
[2]
https://lore.kernel.org/bpf/b1a604e1-be09-ac0b-ff22-b194ae9ce886@isovalent.com/
[3]
https://github.com/libbpf/bpftool/releases
--
Shahab
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
2023-02-09 12:23 ` Shahab Vahedi via buildroot
@ 2023-02-09 20:27 ` Arnout Vandecappelle
-1 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2023-02-09 20:27 UTC (permalink / raw)
To: Shahab Vahedi; +Cc: linux-snps-arc, Alexey Brodkin, buildroot
On 09/02/2023 13:23, Shahab Vahedi wrote:
> Hi Arnout,
>
> On 2/8/23 17:36, Arnout Vandecappelle wrote:
>>
>> It's not clear to me why you did a revert of the cookie feature rather than
>> using those patches. I think the first two or three should be sufficient to
>> fix your issue?
>
> Ideally, the correct way would be applying that pending series. But since
> there were comments that some of the patches might need reworking [1], I did
I don't see anything in that thread about rework being needed, only some
complaints about some mail gateway encrypting messages so they can't be read by
some recipients...
> not feel confident to add them. Therefore, I tried to keep my solution minimal
> and solve it by eliminating the problem. I know, it is not appealing.
The problem with your patch is that it is very difficult to decide if it
should be kept or not when bumping the version. Plus, some people (or other
packages) may rely on the feature that you remove.
Regards,
Arnout
>
>> For the time being, I marked this as Changes Requested. If the upstream
>> patches are not sufficient, please send a mail upstream (as a reply to that
>> series) explaining the problem (again), and re-send this patch to
>> Buildroot. If it does fix things, please send a mail upstream to ask to
>> move the series forward (explaining the issue you have), and send a patch
>> to Buildroot that adds the needed patches.
>
> They (re)confirmed the issue to me in the past [2] and are aware that its
> solution is missing from all the releases onward (see the first point of
> "Known bugs" in the release page [3]).
>
> [1]
> https://lore.kernel.org/bpf/20220421003152.339542-3-alobakin@pm.me/T/#rb9ce86e9f25b2d097b88d87af8ffdfa401d63c68
>
> [2]
> https://lore.kernel.org/bpf/b1a604e1-be09-ac0b-ff22-b194ae9ce886@isovalent.com/
>
> [3]
> https://github.com/libbpf/bpftool/releases
>
> --
> Shahab
>
>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2023-02-09 20:27 ` Arnout Vandecappelle
0 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2023-02-09 20:27 UTC (permalink / raw)
To: Shahab Vahedi; +Cc: buildroot, linux-snps-arc, Alexey Brodkin
On 09/02/2023 13:23, Shahab Vahedi wrote:
> Hi Arnout,
>
> On 2/8/23 17:36, Arnout Vandecappelle wrote:
>>
>> It's not clear to me why you did a revert of the cookie feature rather than
>> using those patches. I think the first two or three should be sufficient to
>> fix your issue?
>
> Ideally, the correct way would be applying that pending series. But since
> there were comments that some of the patches might need reworking [1], I did
I don't see anything in that thread about rework being needed, only some
complaints about some mail gateway encrypting messages so they can't be read by
some recipients...
> not feel confident to add them. Therefore, I tried to keep my solution minimal
> and solve it by eliminating the problem. I know, it is not appealing.
The problem with your patch is that it is very difficult to decide if it
should be kept or not when bumping the version. Plus, some people (or other
packages) may rely on the feature that you remove.
Regards,
Arnout
>
>> For the time being, I marked this as Changes Requested. If the upstream
>> patches are not sufficient, please send a mail upstream (as a reply to that
>> series) explaining the problem (again), and re-send this patch to
>> Buildroot. If it does fix things, please send a mail upstream to ask to
>> move the series forward (explaining the issue you have), and send a patch
>> to Buildroot that adds the needed patches.
>
> They (re)confirmed the issue to me in the past [2] and are aware that its
> solution is missing from all the releases onward (see the first point of
> "Known bugs" in the release page [3]).
>
> [1]
> https://lore.kernel.org/bpf/20220421003152.339542-3-alobakin@pm.me/T/#rb9ce86e9f25b2d097b88d87af8ffdfa401d63c68
>
> [2]
> https://lore.kernel.org/bpf/b1a604e1-be09-ac0b-ff22-b194ae9ce886@isovalent.com/
>
> [3]
> https://github.com/libbpf/bpftool/releases
>
> --
> Shahab
>
>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
2023-02-09 20:27 ` Arnout Vandecappelle
@ 2023-02-10 9:17 ` Shahab Vahedi
-1 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi via buildroot @ 2023-02-10 9:17 UTC (permalink / raw)
To: Arnout Vandecappelle
Cc: linux-snps-arc, Alexey Brodkin, Shahab Vahedi, buildroot
On 2/9/23 21:27, Arnout Vandecappelle wrote:
>
> On 09/02/2023 13:23, Shahab Vahedi wrote:
>>
>> On 2/8/23 17:36, Arnout Vandecappelle wrote:
>>>
>>> It's not clear to me why you did a revert of the cookie feature rather than
>>> using those patches. I think the first two or three should be sufficient to
>>> fix your issue?
>>
>> Ideally, the correct way would be applying that pending series. But since
>> there were comments that some of the patches might need reworking [1], I did
>
> I don't see anything in that thread about rework being needed, only some
> complaints about some mail gateway encrypting messages so they can't be
> read by some recipients...
See this [1] and the response here [2]. Having read it again, apparently it is
not such a big deal. Alexander, the author, mentioned that he will redo that
part in v3 of the patch the way David suggested. So either, I can make that
change when submitting to Buildroot, or take it as it is. Your call.
[1]
https://lore.kernel.org/bpf/20220421003152.339542-3-alobakin@pm.me/T/#m42db58567febf12040f6ba0478e1a6148c284c55
[2]
https://lore.kernel.org/bpf/20220421003152.339542-3-alobakin@pm.me/T/#m293896646128262621c83e8c15c4d977f92ad0d2
>> not feel confident to add them. Therefore, I tried to keep my solution minimal
>> and solve it by eliminating the problem. I know, it is not appealing.
>
> The problem with your patch is that it is very difficult to decide if it
> should be kept or not when bumping the version. Plus, some people (or other
> packages) may rely on the feature that you remove.
I can try to apply that patch series on top of bpftool-v7.1.0-br1.tar.gz in
buildroot. If it can be done fairly easily, I will submit it on a different
thread.
--
Shahab
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2023-02-10 9:17 ` Shahab Vahedi
0 siblings, 0 replies; 43+ messages in thread
From: Shahab Vahedi @ 2023-02-10 9:17 UTC (permalink / raw)
To: Arnout Vandecappelle
Cc: buildroot, linux-snps-arc, Alexey Brodkin, Shahab Vahedi
On 2/9/23 21:27, Arnout Vandecappelle wrote:
>
> On 09/02/2023 13:23, Shahab Vahedi wrote:
>>
>> On 2/8/23 17:36, Arnout Vandecappelle wrote:
>>>
>>> It's not clear to me why you did a revert of the cookie feature rather than
>>> using those patches. I think the first two or three should be sufficient to
>>> fix your issue?
>>
>> Ideally, the correct way would be applying that pending series. But since
>> there were comments that some of the patches might need reworking [1], I did
>
> I don't see anything in that thread about rework being needed, only some
> complaints about some mail gateway encrypting messages so they can't be
> read by some recipients...
See this [1] and the response here [2]. Having read it again, apparently it is
not such a big deal. Alexander, the author, mentioned that he will redo that
part in v3 of the patch the way David suggested. So either, I can make that
change when submitting to Buildroot, or take it as it is. Your call.
[1]
https://lore.kernel.org/bpf/20220421003152.339542-3-alobakin@pm.me/T/#m42db58567febf12040f6ba0478e1a6148c284c55
[2]
https://lore.kernel.org/bpf/20220421003152.339542-3-alobakin@pm.me/T/#m293896646128262621c83e8c15c4d977f92ad0d2
>> not feel confident to add them. Therefore, I tried to keep my solution minimal
>> and solve it by eliminating the problem. I know, it is not appealing.
>
> The problem with your patch is that it is very difficult to decide if it
> should be kept or not when bumping the version. Plus, some people (or other
> packages) may rely on the feature that you remove.
I can try to apply that patch series on top of bpftool-v7.1.0-br1.tar.gz in
buildroot. If it can be done fairly easily, I will submit it on a different
thread.
--
Shahab
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
2023-02-10 9:17 ` Shahab Vahedi
@ 2023-02-10 13:12 ` Arnout Vandecappelle
-1 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2023-02-10 13:12 UTC (permalink / raw)
To: Shahab Vahedi; +Cc: linux-snps-arc, Alexey Brodkin, buildroot
On 10/02/2023 10:17, Shahab Vahedi wrote:
> On 2/9/23 21:27, Arnout Vandecappelle wrote:
>>
>> On 09/02/2023 13:23, Shahab Vahedi wrote:
>>>
>>> On 2/8/23 17:36, Arnout Vandecappelle wrote:
>>>>
>>>> It's not clear to me why you did a revert of the cookie feature rather than
>>>> using those patches. I think the first two or three should be sufficient to
>>>> fix your issue?
>>>
>>> Ideally, the correct way would be applying that pending series. But since
>>> there were comments that some of the patches might need reworking [1], I did
>>
>> I don't see anything in that thread about rework being needed, only some
>> complaints about some mail gateway encrypting messages so they can't be
>> read by some recipients...
> See this [1] and the response here [2]. Having read it again, apparently it is
Ah, but I guessed that that patch was not relevant for the issue you are
facing. I had the impression only the first two or three patches of the series
are relevant.
> not such a big deal. Alexander, the author, mentioned that he will redo that
> part in v3 of the patch the way David suggested. So either, I can make that
> change when submitting to Buildroot, or take it as it is. Your call.
>
> [1]
> https://lore.kernel.org/bpf/20220421003152.339542-3-alobakin@pm.me/T/#m42db58567febf12040f6ba0478e1a6148c284c55
>
> [2]
> https://lore.kernel.org/bpf/20220421003152.339542-3-alobakin@pm.me/T/#m293896646128262621c83e8c15c4d977f92ad0d2
>
>>> not feel confident to add them. Therefore, I tried to keep my solution minimal
>>> and solve it by eliminating the problem. I know, it is not appealing.
>>
>> The problem with your patch is that it is very difficult to decide if it
>> should be kept or not when bumping the version. Plus, some people (or other
>> packages) may rely on the feature that you remove.
>
> I can try to apply that patch series on top of bpftool-v7.1.0-br1.tar.gz in
> buildroot. If it can be done fairly easily, I will submit it on a different
> thread.
Thanks!
Regards,
Arnout
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Buildroot] [PATCH v4 1/1] package/bpftool: revert bpf_cookie patch to allow building
@ 2023-02-10 13:12 ` Arnout Vandecappelle
0 siblings, 0 replies; 43+ messages in thread
From: Arnout Vandecappelle @ 2023-02-10 13:12 UTC (permalink / raw)
To: Shahab Vahedi; +Cc: buildroot, linux-snps-arc, Alexey Brodkin
On 10/02/2023 10:17, Shahab Vahedi wrote:
> On 2/9/23 21:27, Arnout Vandecappelle wrote:
>>
>> On 09/02/2023 13:23, Shahab Vahedi wrote:
>>>
>>> On 2/8/23 17:36, Arnout Vandecappelle wrote:
>>>>
>>>> It's not clear to me why you did a revert of the cookie feature rather than
>>>> using those patches. I think the first two or three should be sufficient to
>>>> fix your issue?
>>>
>>> Ideally, the correct way would be applying that pending series. But since
>>> there were comments that some of the patches might need reworking [1], I did
>>
>> I don't see anything in that thread about rework being needed, only some
>> complaints about some mail gateway encrypting messages so they can't be
>> read by some recipients...
> See this [1] and the response here [2]. Having read it again, apparently it is
Ah, but I guessed that that patch was not relevant for the issue you are
facing. I had the impression only the first two or three patches of the series
are relevant.
> not such a big deal. Alexander, the author, mentioned that he will redo that
> part in v3 of the patch the way David suggested. So either, I can make that
> change when submitting to Buildroot, or take it as it is. Your call.
>
> [1]
> https://lore.kernel.org/bpf/20220421003152.339542-3-alobakin@pm.me/T/#m42db58567febf12040f6ba0478e1a6148c284c55
>
> [2]
> https://lore.kernel.org/bpf/20220421003152.339542-3-alobakin@pm.me/T/#m293896646128262621c83e8c15c4d977f92ad0d2
>
>>> not feel confident to add them. Therefore, I tried to keep my solution minimal
>>> and solve it by eliminating the problem. I know, it is not appealing.
>>
>> The problem with your patch is that it is very difficult to decide if it
>> should be kept or not when bumping the version. Plus, some people (or other
>> packages) may rely on the feature that you remove.
>
> I can try to apply that patch series on top of bpftool-v7.1.0-br1.tar.gz in
> buildroot. If it can be done fairly easily, I will submit it on a different
> thread.
Thanks!
Regards,
Arnout
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2023-02-10 13:12 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-13 21:30 [Buildroot] [PATCH] package/bpftool: revert bpf_cookie patch to allow building Shahab Vahedi via buildroot
2022-06-14 8:26 ` [Buildroot] [PATCH v2 1/1] " Shahab Vahedi via buildroot
2022-06-14 8:26 ` Shahab Vahedi
2022-06-14 9:31 ` [Buildroot] [PATCH v3 " Shahab Vahedi via buildroot
2022-06-14 9:31 ` Shahab Vahedi
2022-06-14 17:14 ` [Buildroot] " Arnout Vandecappelle
2022-06-14 17:14 ` Arnout Vandecappelle
2022-06-14 17:27 ` [Buildroot] " Arnout Vandecappelle
2022-06-14 17:27 ` Arnout Vandecappelle
2022-06-15 11:03 ` [Buildroot] " Shahab Vahedi via buildroot
2022-06-15 11:03 ` Shahab Vahedi
2022-06-15 11:10 ` [Buildroot] " Shahab Vahedi via buildroot
2022-06-15 11:10 ` Shahab Vahedi
2022-06-15 23:27 ` [Buildroot] " James Hilliard
2022-06-15 23:27 ` James Hilliard
2022-06-16 8:11 ` Shahab Vahedi via buildroot
2022-06-16 8:11 ` Shahab Vahedi
2022-06-19 15:20 ` Arnout Vandecappelle
2022-06-19 15:20 ` Arnout Vandecappelle
2022-06-19 23:19 ` James Hilliard
2022-06-19 23:19 ` James Hilliard
2022-06-20 6:45 ` Arnout Vandecappelle
2022-06-20 6:45 ` Arnout Vandecappelle
2022-06-20 9:17 ` James Hilliard
2022-06-20 9:17 ` James Hilliard
2022-06-20 18:27 ` Arnout Vandecappelle
2022-06-20 18:27 ` Arnout Vandecappelle
2022-08-09 9:46 ` James Hilliard
2022-08-09 9:46 ` James Hilliard
2022-06-15 10:57 ` [Buildroot] [PATCH v4 " Shahab Vahedi via buildroot
2022-06-15 10:57 ` Shahab Vahedi
2022-06-24 14:21 ` Shahab Vahedi via buildroot
2022-06-24 14:21 ` Shahab Vahedi
2023-02-08 16:36 ` Arnout Vandecappelle
2023-02-08 16:36 ` Arnout Vandecappelle
2023-02-09 12:23 ` Shahab Vahedi
2023-02-09 12:23 ` Shahab Vahedi via buildroot
2023-02-09 20:27 ` Arnout Vandecappelle
2023-02-09 20:27 ` Arnout Vandecappelle
2023-02-10 9:17 ` Shahab Vahedi via buildroot
2023-02-10 9:17 ` Shahab Vahedi
2023-02-10 13:12 ` Arnout Vandecappelle
2023-02-10 13:12 ` Arnout Vandecappelle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.