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

Andrii Nakryiko andrii.nakryiko at gmail.com
Tue Aug 11 02:54:54 EDT 2020


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!

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