Re: Signedness of char in BTF

[Yonghong Song <yhs@fb.com>]

On 7/21/22 3:21 PM, Jose E. Marchesi wrote:
> 
> 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?

The llvm and pahole generate BTF_INT_BOOL when the dwarf type has
attribute DW_ATE_boolean.
But BTF_INT_BOOL is actually used in libbpf to differentiate
configuration values (CONFIG_* = 'y' vs. CONFIG_* = <value>)

In llvm,
   uint8_t BTFEncoding;
   switch (Encoding) {
   case dwarf::DW_ATE_boolean:
     BTFEncoding = BTF::INT_BOOL;
     break;
   case dwarf::DW_ATE_signed:
   case dwarf::DW_ATE_signed_char:
     BTFEncoding = BTF::INT_SIGNED;
     break;
   case dwarf::DW_ATE_unsigned:
   case dwarf::DW_ATE_unsigned_char:
     BTFEncoding = 0;
     break;
   default:
     llvm_unreachable("Unknown BTFTypeInt Encoding");
   }

For a concrete example,

[$ ~/tmp1] cat t.c
int test(_Bool g) {
    return g;
}
[$ ~/tmp1] clang -target bpf -O2 -g -c t.c
[$ ~/tmp1] bpftool btf dump file t.o
[1] INT '_Bool' size=1 bits_offset=0 nr_bits=8 encoding=BOOL
[2] FUNC_PROTO '(anon)' ret_type_id=3 vlen=1
         'g' type_id=1
[3] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[4] FUNC 'test' type_id=2 linkage=global
[$ ~/tmp1]

> 
>>>> 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