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@xxxxxxxxxx> > > Signed-off-by: Jean-Philippe Brucker <jean-philippe@xxxxxxxxxx> > > 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) > > { > > >
