On Tue, Feb 9, 2021 at 7:03 PM Ilya Leoshkevich <iii@xxxxxxxxxxxxx> 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 >
