On Thu, Nov 30, 2023 at 11:50 AM Jose E. Marchesi <jose.marchesi@xxxxxxxxxx> wrote: > > > > On Tue, Nov 28, 2023 at 8:23 AM Jose E. Marchesi > > <jose.marchesi@xxxxxxxxxx> wrote: > >> > >> > >> [During LPC 2023 we talked about improving communication between the GCC > >> BPF toolchain port and the kernel side. This is the first periodical > >> report that we plan to publish in the GCC wiki and send to interested > >> parties. Hopefully this will help.] > >> > > > > [...] > > > >> Open Questions > >> ============== > >> > >> - BPF programs including libc headers. > >> > >> BPF programs run on their own without an operating system or a C > >> library. Implementing C implies providing certain definitions and > >> headers, such as stdint.h and stdarg.h. For such targets, known as > >> "bare metal targets", the compiler has to provide these definitions > >> and headers in order to implement the language. > >> > >> GCC provides the following C headers for BPF targets: > >> > >> float.h > >> gcov.h > >> iso646.h > >> limits.h > >> stdalign.h > >> stdarg.h > >> stdatomic.h > >> stdbool.h > >> stdckdint.h > >> stddef.h > >> stdfix.h > >> stdint.h > >> stdnoreturn.h > >> syslimits.h > >> tgmath.h > >> unwind.h > >> varargs.h > >> > >> However, we have found that there is at least one BPF kernel self test > >> that include glibc headers that, indirectly, include glibc's own > >> definitions of stdint.h and friends. This leads to compile-time > >> errors due to conflicting types. We think that including headers from > >> a glibc built for some host target is very questionable. For example, > >> in BPF a C `char' is defined to be signed. But if a BPF program > >> includes glibc headers in an android system, that code will assume an > >> unsigned char instead. > >> > > > > Do you have a list of those tests? > > For example: > > progs/test_cls_redirect.c > progs/test_cls_redirect_dynptr.c > progs/test_cls_redirect_subprogs.c > > they include linux/icmp.h that, in turn: > > linux/icmp.h <- linux/if.h <- sys/socket.h <- bits/socket.h <- sys/types.h > > If BPF programs are expected to be able to liberally include kernel > headers that, in turn, may include glibc headers, then it is gonna be > very difficult to consistently avoid these conflicts.. I don't think anyone ever promised this. I think it should be fine to convert all those tests to use vmlinux.h, but we'll need to add a bunch of #defines from UAPI headers (like TC_ACT_SHOT). I see we have tons of those in progs/xdp_synproxy_kern.c, so maybe just extracting that into a separate header would be enough. Ideally TC_ACT_SHOT and other stuff is an enum in UAPI and is just added into vmlinux.h, but someone would need to propose this upstream and do the changes.
