Re: [PATCH v4 bpf-next 2/7] libbpf: Add BTF_KIND_FLOAT support

[Ilya Leoshkevich <iii@linux.ibm.com>]

On Mon, 2021-02-22 at 23:03 -0800, Andrii Nakryiko wrote:
> On Mon, Feb 22, 2021 at 1:50 PM Ilya Leoshkevich <iii@linux.ibm.com>
> wrote:
> > 
> > The logic follows that of BTF_KIND_INT most of the time. Sanitization
> > replaces BTF_KIND_FLOATs with BTF_KIND_CONSTs pointing to
> > equally-sized BTF_KIND_ARRAYs on older kernels, for example, the
> > following:
> > 
> >     [4] FLOAT 'float' size=4
> > 
> > becomes the following:
> > 
> >     [4] CONST '(anon)' type_id=10
> >     ...
> >     [8] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32
> > encoding=(none)
> >     [9] INT 'unsigned char' size=1 bits_offset=0 nr_bits=8
> > encoding=(none)
> >     [10] ARRAY '(anon)' type_id=9 index_type_id=8 nr_elems=4
> > 
> 
> I liked Yonghong's initial suggestion to replace it with PTR to VOID.
> The only concern was that if this type was used from VAR, then
> sizeof(void *) != sizeof(float) on 64-bit architectures, which might
> theoretically mess up DATASEC layout. But is this a real concern? BPF
> programs don't really support floats, so there is no point in
> declaring float variables. I'd rather stick to a simple FLOAT -> PTR
> substitution than extend generated BTF.
> 
> Alternatively, was FLOAT -> anonymous empty STRUCT with desired size
> considered? Any problems with that?

An empty STRUCT is a really nice idea - it's future-proof and has much
smaller implementation than char[]. I'll go for it.

[...]