eBPF CO-RE cross-compilation for 32-bit ARM platforms

Jean-Philippe Brucker jean-philippe at linaro.org
Mon Aug 10 08:57:53 EDT 2020


On Fri, Aug 07, 2020 at 01:54:02PM -0700, Alexei Starovoitov wrote:
[...]
> > > > ```
> > > > typedef __Poly8_t poly8x16_t[16];
> > > > ```
> > > >
> > > > AFAICT these are ARM NEON intrinsic definitions which are GCC-specific. We
> > > > have opted to comment out this line as there was no additional `poly8x16_t`
> > > > usage in the header file.
> > >
> > > It looks like this "__Poly8_t" type is internal to GCC (provided in
> > > arm_neon.h) and clang has its own internals. I managed to reproduce this
> > > with an arm64 allyesconfig kernel (+BTF), but don't know how to fix it at
> > > the moment. Maybe libbpf should generate defines to translate these
> > > intrinsics between clang and gcc? Not very elegant. I'll take another
> > > look next week.
> >
> > libbpf is already blacklisting __builtin_va_list for GCC, so we can
> > just add __Poly8_t to the list. See [0].
> > Are there any other types like that? If you guys can provide me this,
> > I'll gladly update libbpf to take those compiler-provided
> > types/built-ins into account.
> 
> Shouldn't __Int8x16_t and friends cause the same trouble?

I think these do get properly defined, for example in my vmlinux.h:

	typedef signed char int8x16_t[16];

>From a cursory reading of the "ARM C Language Extension" doc (IHI0053D) it
looks like only the poly8/16/64/128_t types are unspecified. It's safe to
drop them as long as they're not used in structs or function parameters,
but I sent a more generic fix [1] that copies the clang defintions. When
building the kernel with clang, the polyX_t types do get typedefs.

Thanks,
Jean

[1] https://lore.kernel.org/bpf/20200810122835.2309026-1-jean-philippe@linaro.org/

> There is a bunch more in gcc/config/arm/arm-simd-builtin-types.def.
> May be there is a way to detect compiler builtin types by pattern matching
> their dwarf/btf shape and skip them automatically?
> The simplest, of course, is to only add a few that caused this known
> trouble to blocklist.



More information about the linux-arm-kernel mailing list