Re: eBPF CO-RE cross-compilation for 32-bit ARM platforms - Jean-Philippe Brucker

From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Luka Perkov <luka.perkov@sartura.hr>,
	Jakov Petrina <jakov.petrina@sartura.hr>,
	Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>,
	Jakov Smolic <jakov.smolic@sartura.hr>, bpf <bpf@vger.kernel.org>,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Andrii Nakryiko <andriin@fb.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: eBPF CO-RE cross-compilation for 32-bit ARM platforms
Date: Mon, 10 Aug 2020 14:57:53 +0200	[thread overview]
Message-ID: <20200810125753.GA1643799@myrica> (raw)
In-Reply-To: <CAADnVQ+fQG38XKR+V33qTR-G-7wm398CMCafbuQrTQ9CHfE2mA@mail.gmail.com>

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel