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@xxxxxxxxxx> 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,
Jean
>
> > [1] https://lore.kernel.org/bpf/20200810122835.2309026-1-jean-philippe@xxxxxxxxxx/
> >
> > > 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.
