[PATCH bpf] libbpf: Handle GCC built-in types for Arm NEON

[Jean-Philippe Brucker]

On Tue, Aug 11, 2020 at 04:10:31PM +0200, Daniel Borkmann wrote:
> On 8/10/20 2:28 PM, Jean-Philippe Brucker wrote:
> > When building Arm NEON (SIMD) code, GCC emits built-in types __PolyXX_t,
> > which are not recognized by Clang. This causes build failures when
> > including vmlinux.h generated from a kernel built with CONFIG_RAID6_PQ=y
> > and CONFIG_KERNEL_MODE_NEON. Emit typedefs for these built-in types,
> > based on the Clang definitions. poly64_t is unsigned long because it's
> > only defined for 64-bit Arm.
> > 
> > Including linux/kernel.h to use ARRAY_SIZE() incidentally redefined
> > max(), causing a build bug due to different types, hence the seemingly
> > unrelated change.
> > 
> > Reported-by: Jakov Petrina <jakov.petrina at sartura.hr>
> > Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
> 
> Looks like this was fixed here [0], but not available on older clang/LLVM
> versions, right?
> 
>   [0] https://reviews.llvm.org/D79711

No, that issue is unrelated. Here the problem is with the DWARF
information generated by GCC. In Linux, lib/raid6/neon.uc uses poly8x16_t,
and the DWARF information provided by GCC for that type uses a base type
named "__Poly8_t", which is only understood by GCC. So after transforming
DWARF->BTF->vmlinux.h, the generated vmlinux.h uses this "__Poly8_t"
without typedefing it to unsigned char. Passing this vmlinux.h to GCC
works because GCC recognizes "__Poly8_t" as one of its internal types, but
passing it to clang fails:

test.h:20:9: error: unknown type name '__Poly8_t'
typedef __Poly8_t poly8x8_t[8];
        ^

On the other hand a kernel built with Clang will have DWARF information
that defines poly8x16_t to be an array of 16 unsigned char.

> [...]
> > +static const char *builtin_types[][2] = {
> > +	/*
> > +	 * GCC emits typedefs to its internal __PolyXX_t types when compiling
> > +	 * Arm SIMD intrinsics. Alias them to the same standard types as Clang.
> > +	 */
> > +	{ "__Poly8_t",		"unsigned char" },
> > +	{ "__Poly16_t",		"unsigned short" },
> > +	{ "__Poly64_t",		"unsigned long" },
> > +	{ "__Poly128_t",	"unsigned __int128" },
> 
> In that above LLVM link [0], they typefdef this to signed types ... which one
> is correct now?
> 
>   // For now, signedness of polynomial types depends on target
>   OS << "#ifdef __aarch64__\n";
>   OS << "typedef uint8_t poly8_t;\n";
>   OS << "typedef uint16_t poly16_t;\n";
>   OS << "typedef uint64_t poly64_t;\n";
>   OS << "typedef __uint128_t poly128_t;\n";
>   OS << "#else\n";
>   OS << "typedef int8_t poly8_t;\n";
>   OS << "typedef int16_t poly16_t;\n";
>   OS << "typedef int64_t poly64_t;\n";
>   OS << "#endif\n";

I don't know why they typedef it to signed types on non-64bit, perhaps
legacy support?  The official doc linked in [0]
(https://developer.arm.com/docs/101028/latest) states that they are
unsigned:

"poly8_t, poly16_t, poly64_t and poly128_t are defined as unsigned integer
types."

Thanks,
Jean

> > +};
> > +
> > +static void btf_dump_emit_int_def(struct btf_dump *d, __u32 id,
> > +				  const struct btf_type *t)
> > +{
> > +	const char *name = btf_dump_type_name(d, id);
> > +	int i;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(builtin_types); i++) {
> > +		if (strcmp(name, builtin_types[i][0]) == 0) {
> > +			btf_dump_printf(d, "typedef %s %s;\n\n",
> > +					builtin_types[i][1], name);
> > +			break;
> > +		}
> > +	}
> > +}
> > +
> >   static void btf_dump_emit_enum_fwd(struct btf_dump *d, __u32 id,
> >   				   const struct btf_type *t)
> >   {
> > 
>