On 6/3/22 8:14 AM, Alexei Starovoitov wrote:
On Fri, Jun 3, 2022 at 4:00 AM Yonghong Song <yhs@xxxxxx> wrote:
+
+SEC("raw_tracepoint/sys_enter")
+int test_core_enum64val(void *ctx)
+{
+#if __has_builtin(__builtin_preserve_enum_value)
+ struct core_reloc_enum64val_output *out = (void *)&data.out;
+ enum named_unsigned_enum64 named_unsigned = 0;
+ enum named_signed_enum64 named_signed = 0;
libbpf: prog 'test_core_enum64val': relo #0: unexpected insn #0
(LDIMM64) value: got 8589934591, exp 18446744073709551615 ->
18446744073709551615
libbpf: prog 'test_core_enum64val': relo #0: failed to patch insn #0: -22
libbpf: failed to perform CO-RE relocations: -22
libbpf: failed to load object 'test_core_reloc_enum64val.o'
Is it failing in CI because clang is too old?
Yes, the failure is due to that the llvm patch to support enum64
is not merged. The llvm patch is not merged because otherwise
people using latest compiler (with llvm patch) may fail to
latest libbpf.
CI will pick up newer clang sooner or later,
but the users will be confused.
The patch 17/18 that updates README certainly helps,
but I was wondering whether we can do a similar trick
to what Andrii did in libbpf and make the error more human readable?
I think the above information is what current libbpf did for
relocation errors.
Unless I missed something, Andrii's commit 9fdc4273b8da ("libbpf: Fix up
verifier log for unguarded failed CO-RE relos") is to improve kernel
verifier log w.r.t. relocation failures.
