Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compilation of minimal failing because kernel header path not in includes #1

Closed
andreimatei opened this issue Nov 30, 2020 · 4 comments · Fixed by #2
Closed

compilation of minimal failing because kernel header path not in includes #1

andreimatei opened this issue Nov 30, 2020 · 4 comments · Fixed by #2

Comments

@andreimatei
Copy link
Contributor

On Ubuntu 20.10 this happens to me:

$ V=1 make minimal
clang -g -O2 -target bpf -D__TARGET_ARCH_x86 -I.output -c minimal.bpf.c -o .output/minimal.bpf.o
In file included from minimal.bpf.c:3:
In file included from /usr/include/linux/bpf.h:11:
/usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
#include <asm/types.h>

The rub seems to be that /usr/include/linux/types.h wants asm/types.h which, on my system, I believe lives in /usr/include/x86_64-linux-gnu/asm/types.h (which file just reads #include <asm-generic/types.h>), and /usr/include/x86_64-linux-gnu does not seem to be among clang's include paths, as demonstrated by the clang -v output below.

clang -v -g -O2 -target bpf -D__TARGET_ARCH_x86 -I.output -c minimal.bpf.c -o .output/minimal.bpf.o
Ubuntu clang version 11.0.0-2
...
#include "..." search starts here:
#include <...> search starts here:
 .output
 /usr/local/include`
 /usr/lib/llvm-11/lib/clang/11.0.0/include
 /usr/include
End of search list.

FWIW, on the gcc side, the preprocessor includes /usr/include/x86_64-linux-gnu in the cpp -v output.

I'm not sure who's at fault here, or what the correct fix is, but adding -I/usr/include/x86_64-linux-gnu makes it work. Changing the source to use vmlinux.h instead of <linux/bpf.h> also makes it work.

Although I don't believe it to be the case, it is possible that my system got screwed up by me manually installing kernel headers through the Debian package created by the kernel's deb-pkg make target. I don't think it's the case because I've verified that /usr/include/linux/types.h corresponds to the file provided by the Ubuntu's linux-libc-dev package.

@andreimatei
Copy link
Contributor Author

Another observation: clang does seem to want to search that arch-specific dir when not using -target bpf:

$ clang -v -g -O2  -D__TARGET_ARCH_x86 -I.output -c minimal.bpf.c -o .output/minimal.bpf.o
Ubuntu clang version 11.0.0-2
...
#include "..." search starts here:
#include <...> search starts here:
 .output
 /usr/local/include
 /usr/lib/llvm-11/lib/clang/11.0.0/include
 /usr/include/x86_64-linux-gnu
 /usr/include

@anakryiko
Copy link
Member

Oh, I think this is how we deal with it in kernel selftests: https://github.com/torvalds/linux/blob/master/tools/testing/selftests/bpf/Makefile#L215-L224

This seems to be due to using -target bpf, so for some systems not all the necessary include paths used... You are right that just using "vmlinux.h" would be enough, but that puts a requirement for kernel BTF on the system, and my goal was to have something to use even without kernel built with BTF...

Do you mind trying the get_sys_includes trick and confirming if that works? We can "backport" it here. Not that it's simple and obvious, but should just work.

@andreimatei
Copy link
Contributor Author

It works indeed. Would you like a patch?

@anakryiko
Copy link
Member

that would be great, thanks. Please also include a comment explaining why we need that.

andreimatei added a commit to andreimatei/libbpf-bootstrap that referenced this issue Dec 3, 2020
Add architecture-specific headers to the BPF compilation command,
otherwise they're missing on some systems (at least on x86-64 Ubuntu).

Fixes libbpf#1
andreimatei added a commit to andreimatei/libbpf-bootstrap that referenced this issue Dec 3, 2020
Add architecture-specific headers to the BPF compilation command,
otherwise they're missing on some systems (at least on x86-64 Ubuntu).

Fixes libbpf#1
andreimatei added a commit to andreimatei/libbpf-bootstrap that referenced this issue Dec 4, 2020
Add architecture-specific headers to the BPF compilation command,
otherwise they're missing on some systems (at least on x86-64 Ubuntu).

Fixes libbpf#1
anakryiko pushed a commit that referenced this issue Dec 4, 2020
Add architecture-specific headers to the BPF compilation command,
otherwise they're missing on some systems (at least on x86-64 Ubuntu).

Fixes #1
ksztyber added a commit to ksztyber/libbpf-bootstrap that referenced this issue Mar 23, 2021
The program accepts 3 connections and then splits the data from the
first one to the other two.  The data is split on a packet boundary and
the packets are alternated betwen the connections.  So for multiple
packets it looks like this:
 - packet 0 -> connection 1,
 - packet 1 -> connection 2,
 - packet 2 -> connection 1,
 - packet 3 -> connection 2, etc.

The easiest way to test it is using netcat:

[shell 0] $ src/sockmap 127.0.0.1 1024
[shell 1] $ nc 127.0.0.1 1024
[shell 2] $ nc 127.0.0.1 1024
[shell 3] $ nc 127.0.0.1 1024

Writing something on shell libbpf#1 will cause it to be redirected and output
to shell libbpf#2.  A second write will be redirectd it to shell libbpf#3, another
one to shell libbpf#2, then libbpf#3, etc.

Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
ksztyber added a commit to ksztyber/libbpf-bootstrap that referenced this issue Mar 31, 2021
The program accepts 3 connections and then splits the data from the
first one to the other two.  The data is split on a packet boundary and
the packets are alternated betwen the connections.  So for multiple
packets it looks like this:
 - packet 0 -> connection 1,
 - packet 1 -> connection 2,
 - packet 2 -> connection 1,
 - packet 3 -> connection 2, etc.

The easiest way to test it is using netcat:

[shell 0] $ src/sockmap 127.0.0.1 1024
[shell 1] $ nc 127.0.0.1 1024
[shell 2] $ nc 127.0.0.1 1024
[shell 3] $ nc 127.0.0.1 1024

Writing something on shell libbpf#1 will cause it to be redirected and output
to shell libbpf#2.  A second write will be redirectd it to shell libbpf#3, another
one to shell libbpf#2, then libbpf#3, etc.

Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants