Em Thu, Nov 29, 2018 at 03:45:49PM -0800, Yonghong Song escreveu:
> For int types, the correct type size will be generated.
> For enum types, if the bit size is not 32,
> current BTF enum cannot represent it so a signed int type will
> be generated.
>
> For the following example,
> $ cat test.c
> enum A { A1, A2, A3 };
> struct t {
> enum A a:3;
> volatile enum A b:4;
> } g;
> $ gcc -c -g -O2 test.c
>
> Without this patch, we will have
> $ pahole -JV test.o
> [1] ENUM A size=4 vlen=3
> A1 val=0
> A2 val=1
> A3 val=2
> [2] STRUCT t size=4 vlen=2
> a type_id=4 bits_offset=0
> b type_id=6 bits_offset=3
> [3] VOLATILE (anon) type_id=1
> [4] ENUM A size=1 vlen=3
> A1 val=0
> A2 val=1
> A3 val=2
> [5] ENUM A size=1 vlen=3
> A1 val=0
> A2 val=1
> A3 val=2
> [6] VOLATILE (anon) type_id=5
> [7] INT (anon) size=4 bit_offset=0 nr_bits=32 encoding=(none)
>
> There are two issues in the above. The struct "t" member "a" points
> to type [4]. But the nr_bits is lost in type [4].
> The same for type [5] which is for struct "t" member "b".
>
> Since BTF ENUM type cannot encode nr_bits, this patch fixed the
> issue by generating a BTF INT type if the ENUM type number of bits
> in pahole is not 32.
Right, I have a script that takes a directory and then goes on encoding
CTF for all object files it finds, and afterwards does a pahole -F dwarf
and a '-F ctf' to then do a diff, and that was one of the things that
got wrong, enums with less than 32 bits.
Tested and applied.
- Arnaldo
