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

[Andrii Nakryiko]

On Tue, Aug 11, 2020 at 2:54 AM Jean-Philippe Brucker
<jean-philippe at linaro.org> wrote:
>
> On Mon, Aug 10, 2020 at 11:54:54PM -0700, Andrii Nakryiko wrote:
> > On Mon, Aug 10, 2020 at 5:58 AM Jean-Philippe Brucker
> > <jean-philippe at linaro.org> wrote:
> > >
> > > 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
> > >
> >
> > Hi Jean,
> >
> > Would you be so kind to build some simple C repro code that uses those
> > polyX_t types? Ideally built by both GCC and Clang. And then run
> > `pahole -J` on them to get .BTF into them as well. If you can share
> > those two with me, I'd love to look at how DWARF and BTF look like.
> >
> > I'm, unfortunately, having trouble making something like that to
> > cross-compile on my x86-64 machine, I've spent a bunch of time already
> > on this unsuccessfully and it's really frustrating at this point. If
> > you have an ARM system (or cross-compilation set up properly), it
> > shouldn't take much time for you, hopefully. Just make sure that those
> > polyX_t types do make it into DWARF, so, e.g., use them with static
> > variable or something, e.g.,:
> >
> > int main() {
> >     static poly8_t a = 12;
> >     return a + 10;
> > }
> >
> > Or something along those lines. Thanks!
>
> No problem, I put the source and clang+gcc binaries in a tarball here:
> https://jpbrucker.net/tmp/test-poly-neon.tar.bz2
>
> These contain all the base types defined by arm_neon.h (minus the new
> bfloat16, which I don't think matters at the moment)
>

Thanks a lot! It was very helpful. I wonder why there was never
poly32_t defined?

> 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.