Re: Signedness of char in BTF

["Jose E. Marchesi" <jose.marchesi@oracle.com>]

Hi Yonghong.

> On 7/21/22 7:54 AM, Jose E. Marchesi wrote:
>> 
>>> Hi Yonghong and Andrii,
>>>
>>> I have some questions re: signedness of chars in BTF. According to [1]
>>> BTF_INT_ENCODING() may be one of SIGNED, CHAR or BOOL.
>> I have always assumed that the bits in `encoding' are non-exclusive
>> i.e. it is a bitmap, not an enumerated.
>
> Based on current BTF design, it is enumerated. So signed char
> is 'signed 1-byte int', unsigned char is 'unsigned 1-byte int'
> and 'char' could be BTF_INT_CHAR but since in debuginfo
> any 'char' has a signedness bit, so it is folded into
> 'signed 1-byte int' or 'unsigned 1-byte int'.

Ok, we will change GCC so it does the same thing.

What about BOOL?  I don't think we ever use that bit.  Does LLVM
generate it for any case?

>>> If I read [2] correctly the signedness of char is implementation
>>> defined. Does this mean that I need to know which implementation
>>> generated the BTF to interpret CHAR correctly?
>>>
>>> Somewhat related, how to I make clang emit BTF_INT_CHAR in the first
>>> place? I've tried with clang-14, but only ever get
>>>
>>>      [6] INT 'unsigned char' size=1 bits_offset=0 nr_bits=8 encoding=(none)
>>>      [6] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
>> Hm, in GCC we currently generate:
>> [1] int 'unsigned char'(0x00000001U#B) size=0x00000001U#B
>> offset=0x00UB#b bits=0x08UB#b CHAR
>> [2] int 'char'(0x00000001U#B) size=0x00000001U#B offset=0x00UB#b bits=0x08UB#b SIGNED CHAR
>> Which turns out is not correct?
>> We used a signed type for `char' because that was what the LLVM BPF
>> toolchain uses, but then we assumed we had to emit the CHAR bit as
>> well... wrong assumption apparently (I just tried with clang 15 and it
>> doesn't set the CHAR bits for neither `char' nor `unsigned char').
>> But then what is the CHAR bit for?
>
> This is not generated by llvm or pahole but apparently it may still
> have some meaning when printing the value, a 'char c' may have
> a dump like 'c' instead of '0x63'. In kernel/bpf/btf.c, we have
>
>                 /*
>                  * BTF_INT_CHAR encoding never seems to be set for
>                  * char arrays, so if size is 1 and element is
>                  * printable as a char, we'll do that.
>                  */
>                 if (elem_size == 1)
>                         encoding = BTF_INT_CHAR;
>
>> 
>>> The kernel seems to agree that CHAR isn't a thing [3].
>>>
>>> Thanks!
>>> Lorenz
>>>
>>> 1: https://www.kernel.org/doc/html/latest/bpf/btf.html#btf-kind-int
>>> 2: https://stackoverflow.com/a/2054941/19544965
>>> 3:
>>> https://sourcegraph.com/github.com/torvalds/linux@353f7988dd8413c47718f7ca79c030b6fb62cfe5/-/blob/kernel/bpf/btf.c?L2928-2934