On Tue, Nov 16, 2021 at 12:40 AM Jean-Philippe Brucker
<jean-philippe@xxxxxxxxxx> wrote:
>
> On Mon, Nov 15, 2021 at 10:10:03PM -0800, Andrii Nakryiko wrote:
> > On Fri, Nov 12, 2021 at 8:28 AM Jean-Philippe Brucker
> > <jean-philippe@xxxxxxxxxx> wrote:
> > >
> > > On Fri, Nov 12, 2021 at 04:17:21PM +0000, Quentin Monnet wrote:
> > > > 2021-11-12 15:51 UTC+0000 ~ Jean-Philippe Brucker <jean-philippe@xxxxxxxxxx>
> > > > > Commit be79505caf3f ("tools/runqslower: Install libbpf headers when
> > > > > building") uses the target libbpf to build the host bpftool, which
> > > > > doesn't work when cross-building:
> > > > >
> > > > > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C tools/bpf/runqslower O=/tmp/runqslower
> > > > > ...
> > > > > LINK /tmp/runqslower/bpftool/bpftool
> > > > > /usr/bin/ld: /tmp/runqslower/libbpf/libbpf.a(libbpf-in.o): Relocations in generic ELF (EM: 183)
> > > > > /usr/bin/ld: /tmp/runqslower/libbpf/libbpf.a: error adding symbols: file in wrong format
> > > > > collect2: error: ld returned 1 exit status
> > > > >
> > > > > When cross-building, the target architecture differs from the host. The
> > > > > bpftool used for building runqslower is executed on the host, and thus
> > > > > must use a different libbpf than that used for runqslower itself.
> > > > > Remove the LIBBPF_OUTPUT and LIBBPF_DESTDIR parameters, so the bpftool
> > > > > build makes its own library if necessary.
> > > > >
> > > > > In the selftests, pass the host bpftool, already a prerequisite for the
> > > > > runqslower recipe, as BPFTOOL_OUTPUT. The runqslower Makefile will use
> > > > > the bpftool that's already built for selftests instead of making a new
> > > > > one.
> > > > >
> > > > > Fixes: be79505caf3f ("tools/runqslower: Install libbpf headers when building")
> > > > > Signed-off-by: Jean-Philippe Brucker <jean-philippe@xxxxxxxxxx>
> > > > Reviewed-by: Quentin Monnet <quentin@xxxxxxxxxxxxx>
> > > >
> > > > I realised too late I should have cc-ed you on those patches, apologies
> > > > for not doing so. Thank you for the fix!
> > >
> > > No worries, I usually try to catch build issues in bpf-next but missed it
> > > this time. I'm still slowly working towards getting automated testing on
> > > Arm targets, which will catch regressions quicker.
> >
> > Are you planning to contribute it to BPF CI? Or you meant you have
> > your own separate system?
>
> At the moment I'm looking at adding it to LKFT, which does regression
> testing on various Arm boards (https://lkft.linaro.org/about/). The only
> bit missing for that is support for cross-building tools with clang, which
> I'll send shortly.
Detecting regressions is good, but preventing regressions is even
better. That's what we are doing with BPF CI. We create a Github PR
and run BPF selftests before patches are applied (see [0] for the
current list of patch sets being reviewed and thus tested). It would
be good to have more support for various architectures there. We
currently have x86-64 and s390x was added just recently. Regressions
still happen, obviously (we don't also control all the other parts of
the kernel so after tree merges things quite often are a bit unstable
and broken, but the system has caught many issues already), but it's
been a tremendous help and time saver. So consider contributing, if
you care about those architectures.
[0] https://github.com/kernel-patches/bpf/pulls
>
> Thanks,
> Jean
