* Re: [Buildroot] [autobuild.buildroot.net] Your daily results for 2022-04-14
[not found] <2098999.irdbgypaU6@pwmachine>
@ 2022-04-17 8:42 ` Thomas Petazzoni via buildroot
2022-04-19 17:41 ` Francis Laniel
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Petazzoni via buildroot @ 2022-04-17 8:42 UTC (permalink / raw)
To: Francis Laniel; +Cc: Yann E. MORIN, buildroot@buildroot.org
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Buildroot] [autobuild.buildroot.net] Your daily results for 2022-04-14
2022-04-17 8:42 ` [Buildroot] [autobuild.buildroot.net] Your daily results for 2022-04-14 Thomas Petazzoni via buildroot
@ 2022-04-19 17:41 ` Francis Laniel
2022-04-19 18:43 ` Thomas Petazzoni via buildroot
0 siblings, 1 reply; 3+ messages in thread
From: Francis Laniel @ 2022-04-19 17:41 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Yann E. MORIN, buildroot@buildroot.org
Hi.
Le dimanche 17 avril 2022, 09:42:44 BST Thomas Petazzoni a écrit :
> 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/fa4fb6ca383e058e89ff8796ac9ae68a0
> > > b16
> > > 81b5 m68k | host-pahole-v1.23 |
> > > http://autobuild.buildroot.net/results/b584c57a72e4604112f4b12c0c7b21e1a
> > > 4b4
> > > 1dd5 arm | host-pahole-v1.23 |
> > > http://autobuild.buildroot.net/results/b43be30cb177066d1b49bf4822790ec0c
> > > a01
> > > 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.
I think upstream code has actually a problem buildroot test infrastructure
highlighted.
So, from my understanding, the best solution would be to patch upstream
libbpf.
Indeed, I do not think adding a buildroot package will solve this problem.
Were you suggesting than by adding a buildroot package we could add a local
patch to fix this behavior?
> Best regards,
>
> Thomas
Best regards.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Buildroot] [autobuild.buildroot.net] Your daily results for 2022-04-14
2022-04-19 17:41 ` Francis Laniel
@ 2022-04-19 18:43 ` Thomas Petazzoni via buildroot
0 siblings, 0 replies; 3+ messages in thread
From: Thomas Petazzoni via buildroot @ 2022-04-19 18:43 UTC (permalink / raw)
To: Francis Laniel; +Cc: Yann E. MORIN, buildroot@buildroot.org
On Tue, 19 Apr 2022 18:41:44 +0100
Francis Laniel <flaniel@linux.microsoft.com> wrote:
> I think upstream code has actually a problem buildroot test infrastructure
> highlighted.
> So, from my understanding, the best solution would be to patch upstream
> libbpf.
> Indeed, I do not think adding a buildroot package will solve this problem.
>
> Were you suggesting than by adding a buildroot package we could add a local
> patch to fix this behavior?
What I meant is that pahole bundles libbpf as a git submodule, but can
also use an external libbpf. In the context of Buildroot, we would very
much prefer to have a separate host-libbpf package, with host-pahole
depending on it (and not using its own copy of 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-04-19 18:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <2098999.irdbgypaU6@pwmachine>
2022-04-17 8:42 ` [Buildroot] [autobuild.buildroot.net] Your daily results for 2022-04-14 Thomas Petazzoni via buildroot
2022-04-19 17:41 ` Francis Laniel
2022-04-19 18:43 ` Thomas Petazzoni via buildroot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox