Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Francis Laniel <flaniel@linux.microsoft.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>,
	"buildroot@buildroot.org" <buildroot@buildroot.org>
Subject: Re: [Buildroot] [autobuild.buildroot.net] Your daily results for 2022-04-14
Date: Sun, 17 Apr 2022 10:42:44 +0200	[thread overview]
Message-ID: <20220417104244.6d681b10@windsurf> (raw)
In-Reply-To: <2098999.irdbgypaU6@pwmachine>

On Fri, 15 Apr 2022 17:42:23 +0100
Francis Laniel <flaniel@linux.microsoft.com> wrote:


> >     arch     |             reason             |                             
> >          url
> > -------------+--------------------------------+----------------------------
> > ----------------------------------------------------- xtensa    |      
> > host-pahole-v1.23        |
> > http://autobuild.buildroot.net/results/fa4fb6ca383e058e89ff8796ac9ae68a0b16
> > 81b5 m68k     |       host-pahole-v1.23        |
> > http://autobuild.buildroot.net/results/b584c57a72e4604112f4b12c0c7b21e1a4b4
> > 1dd5 arm      |       host-pahole-v1.23        |
> > http://autobuild.buildroot.net/results/b43be30cb177066d1b49bf4822790ec0ca01
> > 9d03
> > 
> > 
> > Thanks for your contribution to Buildroot!  
> 
> I suspect this problem occurs because Ubuntu 14.04 kernel does not know the 
> problematic symbols.
> Indeed, PERF_COUNT_SW_BPF_OUTPUT was added in :
> a43eec304259 ("bpf: introduce bpf_perf_event_output() helper")
> which was released with kernel 4.4.
> So, can you please give me the uname -r of the host-distro?

I can't because these build issues (or at least the last one) occurs on
Yann Morin's autobuilder, so I've added yann in Cc.

> If my suspicion is good, I already wrote a patch to throw an error if host 
> kernel is under 4.4 while building host-pahole.

This is not going to be the solution. Why does host-pahole depend on
the version of the kernel? Why does it need the NR_bpf symbol?

There is some logic in src/bpf.c to get __NR_bpf if not provided by
kernel headers:

#ifndef __NR_bpf
# if defined(__i386__)
#  define __NR_bpf 357
# elif defined(__x86_64__)
#  define __NR_bpf 321
# elif defined(__aarch64__)
#  define __NR_bpf 280
# elif defined(__sparc__)
#  define __NR_bpf 349
# elif defined(__s390__)
#  define __NR_bpf 351
# elif defined(__arc__)
#  define __NR_bpf 280
# elif defined(__mips__) && defined(_ABIO32)
#  define __NR_bpf 4355
# elif defined(__mips__) && defined(_ABIN32)
#  define __NR_bpf 6319
# elif defined(__mips__) && defined(_ABI64)
#  define __NR_bpf 5315
# else
#  error __NR_bpf not defined. libbpf does not support your arch.
# endif
#endif

but this logic is only partially duplicated in src/skel_internal.h:

#ifndef __NR_bpf
# if defined(__mips__) && defined(_ABIO32)
#  define __NR_bpf 4355
# elif defined(__mips__) && defined(_ABIN32)
#  define __NR_bpf 6319
# elif defined(__mips__) && defined(_ABI64)
#  define __NR_bpf 5315
# endif
#endif

That doesn't make much sense.

Do we need that BPF support in host-pahole in our use-case of host-pahole?

BTW, I'm seeing that we can avoid using the internal libbpf, and
therefore avoid using git submodules:

option(LIBBPF_EMBEDDED "Use the embedded version of libbpf instead of searching it via pkg-config" ON)
if (NOT LIBBPF_EMBEDDED)
        find_package(PkgConfig REQUIRED)
        if(PKGCONFIG_FOUND)
                pkg_check_modules(LIBBPF REQUIRED libbpf>=0.4.0)
        endif()
endif()

So we should definitely do that, and have a separate Buildroot package
for libbpf.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

       reply	other threads:[~2022-04-17  8:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2098999.irdbgypaU6@pwmachine>
2022-04-17  8:42 ` Thomas Petazzoni via buildroot [this message]
2022-04-19 17:41   ` [Buildroot] [autobuild.buildroot.net] Your daily results for 2022-04-14 Francis Laniel
2022-04-19 18:43     ` Thomas Petazzoni via buildroot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220417104244.6d681b10@windsurf \
    --to=buildroot@buildroot.org \
    --cc=flaniel@linux.microsoft.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=yann.morin.1998@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox