> 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!
Pushed to master. 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;
