Re: BPF GCC status - Nov 2023

["Jose E. Marchesi" <jose.marchesi@oracle.com>]

> On Tue, Nov 28, 2023 at 8:23 AM Jose E. Marchesi
> <jose.marchesi@oracle.com> 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..