Re: Problem with endianess of pahole BTF output for vmlinux

[Juraj Vijtiuk <juraj.vijtiuk@sartura.hr>]

Hello Andrii and Tony,

as Luka mentioned we do not yet have a final version of the testing
environment that we are working on for ARM32.

However, I previously created an ARM32 little endian QEMU virt image
that runs Debian, to test issues that we encountered with BPF CO-RE
programs on ARM32.
I only managed to get BPF CO-RE programs working with the default
Debian kernel image, which is version 4.19. I built a custom 5.7
kernel but it has some issues (none of the BPF programs work), which i
haven't managed to fix yet.
I'm not sure if the issue is due to the 5.7 kernel image, or due to
the QEMU image. Because of that I'm not sure if it will work with
other kernel versions, but if you are interested in trying to use it,
it is available at the following Google Drive link:
https://drive.google.com/drive/folders/1hs80tYhQG76As7_vkj1y7EF-sFXWxep1?usp=sharing

To run the command i use "qemu-system-arm -M virt -m 1024 -kernel
vmlinuz-4.19.0-10-armmp-lpae -initrd initrd.img-4.19.0-10-armmp-lpae
-append 'root=/dev/vda2' -drive
if=none,file=qemu-backup.qcow2,format=qcow2,id=hd -device
virtio-blk-device,drive=hd -netdev user,id=mynet -device
virtio-net-device,netdev=mynet -nographic".

The logins are root:test and user:user.
The link has the disk image in qemu-backup.qcow, the 4.19 kernel and
initrd and a run.sh which has the above mentioned command to run the
image.

Regards,
Juraj


On Tue, Sep 29, 2020 at 8:48 AM Tony Ambardar <tony.ambardar@gmail.com> wrote:
>
> On Mon, 28 Sep 2020 at 21:15, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> >
> > On Mon, Sep 28, 2020 at 8:41 PM Tony Ambardar <tony.ambardar@gmail.com> wrote:
> > >
> [...]
> > > I can provide 32-bit and 64-bit big-endian system images for running
> > > on QEMU's malta target. These are built using OpenWRT's build system
> > > and include a recent stable bpftool (v5.8.x) and v5.4.x kernel. Is
> > > that sufficient? It would work if manually creating raw or elf-based
> > > BTF files on a build host, then copying into the QEMU target to test
> > > parsing with bpftool (linked with the standard libbpf).
> >
> > That would be great! I intend to run them under qemu-system-arm and
> > supply latest kernel through -kernel option, so kernel itself is not
> > that critical. Same for bpftool, pahole, etc, I'll just supply them
> > from my host environment. So please let me know how I can get ahold of
> > those. Sample qemu invocation command line would be highly appreciated
> > as well. Thank you!
> >
> Sounds good. However, malta is actually a MIPS platform. I've been using it
> a long time because it makes things particularly easy to switch configuration
> between different word-sizes and endianness.
>
> I had some malta mips images ready to go, but if you need ARM I'll need
> to look into building images for big-endian ARM. Big-endian isn't so common
> in the wild, and I'll need to see if OpenWRT supports these, and how to
> configure with QEMU's 'armvirt' target if possible...
>
> > >
> > > For changes to the Linux build system itself (e.g. pahole endian
> > > options and target endian awareness), you would need to set up a
> >
> > I think that shouldn't be a problem and should be handled
> > transparently, even in a cross-compilation case, but let's see.
> >
> > > standard OpenWRT build environment. I can help with that, or simply
> > > integrate your patches myself for testing. As you say, nothing to be
> > > super pumped about...
> > >
> > > Let me know what's easiest and how best to get images to you.
> >
> > Any way you like and can. Dropbox, Google drive, what have you.
> >
> Meantime, I can package up what I have and send you the details. That
> would include images for mips32/64 big-endian and arm32/64 little-endian,
> plus usage examples. Is that still helpful for you?
>
> Thanks,
> Tony