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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Alan




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux