[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5ddda9354c976_9832aef3a62e5b8ab@john-XPS-13-9370.notmuch>
Date: Tue, 26 Nov 2019 14:37:41 -0800
From: John Fastabend <john.fastabend@...il.com>
To: Stanislav Fomichev <sdf@...gle.com>, netdev@...r.kernel.org,
bpf@...r.kernel.org
Cc: davem@...emloft.net, ast@...nel.org, daniel@...earbox.net,
Stanislav Fomichev <sdf@...gle.com>
Subject: RE: [PATCH bpf] bpf: support pre-2.25-binutils objcopy for vmlinux
BTF
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.
Can we print a useful help message instead so users can disable
CONFIG_DEBUG_INFO_BTF or update binutils?
>
> Documentation/process/changes.rst states that binutils 2.21+
> is supported, not sure those standards apply to BPF subsystem.
>
> Fixes: 341dfcf8d78ea ("btf: expose BTF info through sysfs")
> Signed-off-by: Stanislav Fomichev <sdf@...gle.com>
> ---
> scripts/link-vmlinux.sh | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Powered by blists - more mailing lists