From: Stanislav Fomichev <sdf@fomichev.me>
To: John Fastabend <john.fastabend@gmail.com>
Cc: Stanislav Fomichev <sdf@google.com>,
netdev@vger.kernel.org, bpf@vger.kernel.org, davem@davemloft.net,
ast@kernel.org, daniel@iogearbox.net
Subject: Re: [PATCH bpf] bpf: support pre-2.25-binutils objcopy for vmlinux BTF
Date: Tue, 26 Nov 2019 14:47:47 -0800 [thread overview]
Message-ID: <20191126224747.GD3145429@mini-arch.hsd1.ca.comcast.net> (raw)
In-Reply-To: <5ddda9354c976_9832aef3a62e5b8ab@john-XPS-13-9370.notmuch>
On 11/26, John Fastabend wrote:
> Stanislav Fomichev wrote:
> > If vmlinux BTF generation fails, but CONFIG_DEBUG_INFO_BTF is set,
> > .BTF section of vmlinux is empty and kernel will prohibit
> > BPF loading and return "in-kernel BTF is malformed".
> >
> > --dump-section argument to binutils' objcopy was added in version 2.25.
> > When using pre-2.25 binutils, BTF generation silently fails. Convert
> > to --only-section which is present on pre-2.25 binutils.
>
> hmm I think we should fail hard if a feature explicitly asked for
> in the .config is not able to be built due to tooling. Otherwise
> users may later try to use a feature that can only be supported by
> BTF and that will have to fail at runtime. The runtime failure
> seems more likely to surprise users compared to the inconvience
> of having a compile time error. I view this similar to how having
> old ssl libs fails the build with the various signing options are
> set.
I agree. This is what actually happened to me. At some point
all my selftests started to fail.
> Can we print a useful help message instead so users can disable
> CONFIG_DEBUG_INFO_BTF or update binutils?
I'm not sure objcopy returns with error if it fails to execute the command.
I guess we can query the size of .BTF section in vmlinux and print
an error if it's empty.
Another thing we can do is to add a special 'data_size == 0' to
btf_parse_vmlinux. That way, at least, kernel can fall-back to
pre-BTF world instead of assuming that BTF is malformed (it's not
malformed, it's just not there). But that's, again, a surprise
at runtime. Checking at build time seems like a better option.
prev parent reply other threads:[~2019-11-26 22:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-26 17:42 [PATCH bpf] bpf: support pre-2.25-binutils objcopy for vmlinux BTF Stanislav Fomichev
2019-11-26 22:30 ` Andrii Nakryiko
2019-11-26 22:37 ` John Fastabend
2019-11-26 22:47 ` Stanislav Fomichev [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191126224747.GD3145429@mini-arch.hsd1.ca.comcast.net \
--to=sdf@fomichev.me \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=john.fastabend@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).