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.
