* 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