On Sat, Jun 4, 2022 at 4:51 AM Yonghong Song <yhs@xxxxxx> wrote:
>
>
>
> 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.
Right. I was referring to the spirit of that commit.
libbpf can probably print more user friendly message and point out
that enum64 is potentially missing in the clang?
