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

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
[off-list ref] wrote:

quoted

On Fri, Aug 07, 2020 at 01:54:02PM -0700, Alexei Starovoitov wrote:
[...]

quoted

quoted

quoted

quoted

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

quoted

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

quoted

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