On 8/2/22 08:42, Jose E. Marchesi wrote:
>
>> On 7/26/22 14:58, Indu Bhagat wrote:
>>> On 7/22/22 4:23 AM, Jose E. Marchesi via Gcc-patches wrote:
>>>>
>>>> Contrary to CTF and our previous expectations, as per [1], turns out
>>>> that in BTF:
>>>>
>>>> 1) The `encoding' field in integer types shall not be treated as a
>>>> bitmap, but as an enumerated, i.e. these bits are exclusive to each
>>>> other.
>>>>
>>>> 2) The CHAR bit in `encoding' shall _not_ be set when emitting types
>>>> for char nor `unsigned char'.
>>>>
>>>
>>> Hmm...well. At this time, I suggest we make a note of this in the btf.h
>>> for posterity that BTF_INT_CHAR is to not be used (i.e., BTF_INT_CHAR
>>> should not be set for char / unsigned char).
>>
>> Agreed it would be good to add this note.
>
> Hmm, I am not sure such a comment actually belongs to include/btf.h,
> which is not specific to the compiler and is supposed to reflect the BTF
> format per-se. The CHAR bit is documented in the kernel documentation
> and it may be used at some point by bpflib, or who knows what.
OK you make a good point.
In that case the patch LGTM to commit. Thanks!
>
> That's why I put the comment in btfout.cc instead, to make it clear that
> BTF_INT_CHAR is indeed not to be set for char / unsigned char by the
> compiler:
>
>>>> + /* In BTF the CHAR `encoding' seems to not be used, so clear it
>>>> + here. */
>>>> + dtd->dtd_u.dtu_enc.cte_format &= ~BTF_INT_CHAR;
