On Tue, Dec 20, 2022 at 7:55 PM Leo Yan leo.yan@linaro.org wrote:
On Tue, Dec 20, 2022 at 04:13:13PM -0800, Andrii Nakryiko wrote:
[...]
@@ -990,6 +990,7 @@ static struct btf *btf_parse_elf(const char *path, struct btf *base_btf, err = 0;
if (!btf_data) {
pr_warn("failed to find '%s' ELF section in %s\n", BTF_ELF_SEC, path); err = -ENOENT;btf_parse_elf() returns -ENOENT when ELF file doesn't contain BTF section, therefore, bpftool dumps error string "No such file or directory". It's confused that actually vmlinux is existed.
I am wondering if we can use error -LIBBPF_ERRNO__FORMAT (or any better choice?) to replace -ENOENT at here, this can avoid bpftool to outputs "No such file or directory" in this case.
The only really meaningful error code would be -ESRCH, which strerror() will translate to "No such process", which is also completely confusing.
Or maybe -ENODATA (No data available) is a better choice?
-ENODATA sounds good to me, yep.
Thanks, Leo
In general, I always found these strerror() messages extremely unhelpful and confusing. I wonder if we should make an effort to actually emit symbolic names of errors instead (literally, "-ENOENT" in this case). This is all tooling for engineers, I find -ENOENT or -ESRCH much more meaningful as an error message, compared to "No such file" seemingly human-readable interpretation.
Quenting, what do you think about the above proposal for bpftool? We can have some libbpf helper internally and do it in libbpf error messages as well and just reuse the logic in bpftool, perhaps?
Anyways, I've applied this patch set to bpf-next. Thanks.