Re: Bug#1076564: pahole BTF processing seems flaky on powerpc

[Arnaldo Carvalho de Melo <acme@kernel.org>]

On Wed, Jul 24, 2024 at 11:04:51AM +0100, Alan Maguire wrote:
> On 19/07/2024 20:13, Arnaldo Carvalho de Melo wrote:
> > Adding Alan and Jiri to the CC list.
> >
> 
> I'm late chiming in on this one, but judging by the output:
> 
>   BTF     .btf.vmlinux.bin.o
> + LLVM_OBJCOPY=powerpc-linux-gnu-objcopy pahole -J -j
> --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func
> --lang_exclude=rust .tmp_vmlinux.btf
> [102044] ARRAY (anon) type_id=99491 index_type_id=14 nr_elems=12 Error
> emitting BTF type
> Encountered error while encoding BTF.
> 
> 
> ...we hit an error in btf_encoder__add_array() as a result of
> btf__add_array() failing:
> 
> btf__log_err(btf, BTF_KIND_ARRAY, NULL, true,
>                               "type_id=%u index_type_id=%u nr_elems=%u
> Error emitting BTF type",
>                               type, index_type, nelems);
> 
> 
> Unfortunately we don't preserve the negative id value (containing the
> error code) in btf__log_err(); I'm thinking one thing we should do is
> modify btf__log_err() to preserves errors for cases where the encoding
> errors out due to a libbpf-returned -errno, something like
> 
> 
> -__attribute ((format (printf, 5, 6)))
> +__attribute ((format (printf, 6, 7)))
> -static void btf__log_err(const struct btf *btf, int kind, const char *name,
> +static void btf__log_err(const struct btf *btf, int libbpf_err, int
> kind, const char *name,
>                          bool output_cr, const char *fmt, ...)
> {
>         fprintf(stderr, "[%u] %s %s", btf__type_cnt(btf),
>                 btf_kind_str[kind], name ?: "(anon)");
> 
> 	if (fmt && *fmt) {
>                 va_list ap;
> 
>                 fprintf(stderr, " ");
>                 va_start(ap, fmt);
>                 vfprintf(stderr, fmt, ap);
>                 va_end(ap);
>         }
> 
> +	if (libbpf_err)
> +		fprintf(stderr, " libbpf error %d", libbpf_err);
>         if (output_cr)
>                 fprintf(stderr, "\n");
> }
> 
> 
> So at least if this error recurs we'd have a clearer picture of what's
> happening in libbpf. What do you think? I'll submit a patch for this if
> it makes sense.

I agree completely that the error reporting we have is lacking, we
better go and add extra info for these cases so that we can more quickly
get a clue of what is taking place, so please submit patches for that
and I'll consider them.

Thanks,

- Arnaldo