Re: [PATCH RFC 0/6] Add BTF_KIND_FLOAT support

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Tue, Feb 9, 2021 at 7:03 PM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> Some BPF programs compiled on s390 fail to load, because s390
> arch-specific linux headers contain float and double types.
>
> Introduce support for such types by representing them using the new
> BTF_KIND_FLOAT. This series deals with libbpf, bpftool, in-kernel BTF
> parser as well as selftests and documentation.
>
> There are also pahole and LLVM parts:
>
> * https://github.com/iii-i/dwarves/commit/btf-kind-float-v1
> * https://reviews.llvm.org/D83289
>
> but they should go in after the libbpf part is integrated.
>
> There is also an open question: should we go forward with
> BTF_KIND_FLOAT, or should this be merely a BTF_KIND_INT encoding? The
> argument for BTF_KIND_FLOAT is that it's more explicit and therefore
> less prone to unintentional mixups. The argument for BTF_KIND_INT
> encoding is that there would be less code and the overall integration
> process would be simpler.

Less code is not the only or main motivation for representing floats
as just an encoding of BTF_KIND_INT. I think float is not sufficiently
different from bool and int to warrant its own type (kind). And BTF,
in general, is pretty good about having only essential types (kinds).
Float/double is a primitive type, just like bool or char/int/long,
supported by the compiler natively and it represents some indivisible
arrangement of bits in memory.

Surely, there are some semantic differences in how compiler and CPU
are handling such types, but that's none of type system's concern.
E.g., ABI calling conventions dictating which registers or stack
locations arguments go into are not described by BTF. Also, consider
bool. You can treat it as a single byte integer, but it's not just
that: compiler treats it specially (with the 0 and 1 regularization,
when converting to integer representation). Similarly for floats, code
generated for use of floats will be different from integers, but
that's none of type system's concerns. But when using BTF types to
describe memory contents, bool, int, and float are exactly the same
thing: a set of bytes in memory, which are up to interpretation. And
that's why it leads to less code and overall simpler integration.

The only place I can think of where BPF verifier would care about
float vs int, is when processing function signature, because (at least
for some architectures) float will be put in different registers than
non-floats. But BPF verifier can easily distinguish that case by
checking the encoding, so I don't buy the "unintentional mixups"
argument.


>
> Ilya Leoshkevich (6):
>   bpf: Add BTF_KIND_FLOAT to uapi
>   libbpf: Add BTF_KIND_FLOAT support
>   tools/bpftool: Add BTF_KIND_FLOAT support
>   bpf: Add BTF_KIND_FLOAT support
>   selftest/bpf: Add BTF_KIND_FLOAT tests
>   bpf: Document BTF_KIND_FLOAT in btf.rst
>
>  Documentation/bpf/btf.rst                    |  19 ++-
>  include/uapi/linux/btf.h                     |  10 +-
>  kernel/bpf/btf.c                             | 101 ++++++++++++-
>  tools/bpf/bpftool/btf.c                      |  13 ++
>  tools/bpf/bpftool/btf_dumper.c               |   1 +
>  tools/include/uapi/linux/btf.h               |  10 +-
>  tools/lib/bpf/btf.c                          |  85 ++++++++---
>  tools/lib/bpf/btf.h                          |  13 ++
>  tools/lib/bpf/btf_dump.c                     |   4 +
>  tools/lib/bpf/libbpf.c                       |  32 +++-
>  tools/lib/bpf/libbpf.map                     |   5 +
>  tools/lib/bpf/libbpf_internal.h              |   4 +
>  tools/testing/selftests/bpf/btf_helpers.c    |   4 +
>  tools/testing/selftests/bpf/prog_tests/btf.c | 145 +++++++++++++++++++
>  tools/testing/selftests/bpf/test_btf.h       |   5 +
>  15 files changed, 418 insertions(+), 33 deletions(-)
>
> --
> 2.29.2
>