On Sat, Aug 27, 2022 at 03:13:41AM +0200, Jose E. Marchesi wrote:
Users can migrate away from libc headers over time, migrating away
imo, not without a good reason.
Something that may be a good reason is that there is no BPF port of glibc (nor of musl, nor of newlib.) And given BPF's restrictions as an architecture (no more than 5 arguments supported in function calls, etc) it is very unlikely that there will ever be one.
Including certain libc headers may work well enough, but in general when including libc headers you risk dragging in x86, or aarch64, or whatever architecture-specific headers as well, directly or indirectly. C libraries (and system libraries in general) are targetted at particular architectures/ABIs/OSes.
This means that the same BPF program may be using different data structures depending on the system where you build it.
Note that the data structure difference is not unique to different arch. A more common case can already happen across different kernel versions or different kconfig of the same arch. BPF CO-RE is there to handle this case.
In the worst case, it may choke on assembler snippets.
Thats why the GCC port offers certain headers to provide standard C, like stdint.h. That's the usual way to go for bare-metal targets where no libc is available.
Again, we will be happy to change that if that's what you want. In that case, it will be up to the user to provide the standard definitions, be it by including glibc headers targetted at some other architecture, or by some other mean. Not that I would personally recommend that, but it is up to you.
Not sure if the user can always stay with vmlinux.h + a few bpf_tracing_*.h and if that is enough to avoid knowing this difference between GCC and LLVM bpf on libc-vs-gcc stdint...etc.
The header changes is hard to swim through to make it compile in GCC BPF. In this case, it is because netinet/tcp.h brought in a different int8_t from gcc than the sys/socket.h. My preference is not to have to dive into this kind of header details. I would like to hear how others think about it.
shouldn't cause regressions and should improve reliability.
May be I am missing something. I also don't understand the reliability part.
In this sys/socket.h as an example, what is wrong in using "'int8_t' {aka 'signed char'}" from libc and the one from gcc "'int8_t'; have 'char'" must be used instead.
Why LLVM bpf does not have issue ?
The solution should be on the GCC-BPF side instead of changing all bpf progs.
I mean, GCC doesn't really control which libc is available, it seems to be a bad idea to use libc headers in general as they are developed separately from GCC and the kernel/libbpf.
I'm not really sure how one would fix this on the GCC-BPF side without introducing more potential header conflicts.