On Mon, 2021-02-22 at 23:03 -0800, Andrii Nakryiko wrote: > On Mon, Feb 22, 2021 at 1:50 PM Ilya Leoshkevich <iii@xxxxxxxxxxxxx> > 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. [...]
