From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62B6CC4332F for ; Wed, 21 Dec 2022 03:55:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234250AbiLUDzi (ORCPT ); Tue, 20 Dec 2022 22:55:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234161AbiLUDzd (ORCPT ); Tue, 20 Dec 2022 22:55:33 -0500 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 865241EEEF for ; Tue, 20 Dec 2022 19:55:32 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id s7so14318357plk.5 for ; Tue, 20 Dec 2022 19:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=LG53lA26L/ncngjFCHRhyvrs5xf1POMXaF/i7pP2T2w=; b=jE8ug6sV2Ksmc1BjKlm2igxId/ENjDWpxJUXauuLCDWxTXh5ogm7qEZcDK557UrubC CrP+Ib8pkTZdIZEdo3nkWvf5LrUWmr4jzVAoTsF/GdW73ifIopte2waaoubyn/9pOerY WAfRkiwcznSlocee7G/hOSFzDtFRdLMj3soEhqVIsFxGlXL84laUyc3rDUUFohWw9FGU 5ITGwmYLdSoJpaDqay0DHYJdne1DhHXdxu/ZhO87WLlQPJXGXJ9pxE54c3n2Yam5WAMJ Z4jmRQbXMkrl9CI0akL6yhV89RmgjdmqRaldmqh7AzpJGJFOPNEePFm2YBQD/wudUzJD Jzxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LG53lA26L/ncngjFCHRhyvrs5xf1POMXaF/i7pP2T2w=; b=bBEBWPIeQjGmlS1/IYpcG7gFekLEXskfnPw7EgIhvDjTiIJkCqtS39/5v3eJjqk+8s WcIdFzLFQJRK5XKG2uyWdCpN4pcd3x0yqwjL1cIXCcWdtRKJzq/ymxuWnr1tqAc0qKpL +EF9piE9oiIAF0MIK5m1o5vtLCVliZQTJ0UEUqAln9ccAtrAEqq9/L/AZZ89UHBo5Ywl rQ4a/iN3P91129SjFTV5Wp0sAETeormKu1bncopVjsth2EUASJY1ML83nTvi52b1KJT+ L+E/kGUIyz7oP2DOxMpBvO0PrOzuwsbwfWpe1eiVT4jCUI5uKTOb96y5PnOn6L9IRxT3 31rg== X-Gm-Message-State: AFqh2krGlQdR3PxpOOHq7pZ3DWrblnJ5bappkz6QQ9JeJZATu0YjV3GT hBajDmWW9buF02BNXrQAn4vlAQ== X-Google-Smtp-Source: AMrXdXucR+r5a6DTmL41q4+SegBpEAwe4Wonw64R9urkdQSpXNK8K3BOVXCMoHZst4hjRq8i7ONt9w== X-Received: by 2002:a17:902:7405:b0:18f:a4e1:9908 with SMTP id g5-20020a170902740500b0018fa4e19908mr661321pll.15.1671594931937; Tue, 20 Dec 2022 19:55:31 -0800 (PST) Received: from leoy-yangtze.lan (n058152048225.netvigator.com. [58.152.48.225]) by smtp.gmail.com with ESMTPSA id d5-20020a170902654500b00188fcc4fc00sm10165715pln.79.2022.12.20.19.55.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Dec 2022 19:55:31 -0800 (PST) Date: Wed, 21 Dec 2022 11:55:24 +0800 From: Leo Yan To: Andrii Nakryiko Cc: Quentin Monnet , Changbin Du , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Shuah Khan , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Rutland , Alexander Shishkin , Namhyung Kim , Mykola Lysenko , linux-perf-users@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v3 1/2] libbpf: show error info about missing ".BTF" section Message-ID: References: <20221217223509.88254-1-changbin.du@gmail.com> <20221217223509.88254-2-changbin.du@gmail.com> <20221220013114.zkkxkqh7orahxbzh@mail.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? 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.