Skip to contentSkip to conversation

Your daily results for 2022-04-14

Buildroot Thomas Petazzoni via buildroot 2 participants 3 messages Apr 17, 2022 – Apr 19, 2022 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): 2098999.irdbgypaU6@pwmachine

Thomas Petazzoni via buildroot

author
#1 lore raw
Quoted 13 lines · On Fri, 15 Apr 2022 17:42:23 +0100 Francis Laniel…
Quoted 13 lines

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

Quoted 8 lines
Quoted 1 line

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.

Quoted 2 lines

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

Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
#2 lore raw

Hi.

Quoted 95 lines · Le dimanche 17 avril 2022, 09:42:44 BST Thomas Petazzoni a écrit :

On Fri, 15 Apr 2022 17:42:23 +0100

Quoted 21 lines · Francis Laniel
Quoted 19 lines

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

Quoted 1 line

Thanks for your contribution to Buildroot!

Quoted 7 lines

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.

Quoted 2 lines

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()

Quoted 2 lines

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?

Quoted 3 lines

Best regards,

Thomas

Best regards.

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

author
#3 lore raw
Quoted 8 lines · On Tue, 19 Apr 2022 18:41:44 +0100 Francis Laniel…

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

Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot