Hello Andrii! On Mon, 28 Sep 2020 at 13:19, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > On Mon, Sep 21, 2020 at 11:19 AM Andrii Nakryiko > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > I have a bunch of code changes locally. I'll clean that up, partition > > libbpf and pahole patches, and post them for review this week. To > > address endianness support, those are the prerequisites. Once those > > changes land, I'll be able to solve endianness issues you are having. > > So just a bit longer till all that is done, sorry for the wait! > > > > Question to folks that are working with 32-bit and/or big-endian > architectures. Do you guys have an VM image that you'd be able to > share with me, such that I can use it with qemu to test patches like > this. My normal setup is all 64-bit/little-endian, so testing changes > like this (and a few more I'm planning to do to address mixed 32-bit > on the host vs 64-bit in BPF cases) is a bit problematic. And it's > hard to get superpumped about spending lots of time setting up a new > Linux image (never goes easy or fast for me). > > So, if you do have something like this, please share. Thank you! > 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). For changes to the Linux build system itself (e.g. pahole endian options and target endian awareness), you would need to set up a 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. Many thanks, Tony
