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?
