search

foniod / redbpf

Rust library for building and running BPF/eBPF modules
Apache License 2.0
1.71k stars 136 forks source link

LLVM default version #248

Open rhdxmr opened 2 years ago

rhdxmr commented 2 years ago

Should we bump up RedBPF major version when we change the default LLVM version? I think changing the default llvm causes compile errors on user side even if they don't touch anything.

How do you think about this? Is it better to get rid of default llvm and let users specify --features=llvmXX?

rsdy commented 2 years ago

Actually releasing a new major version on LLVM changes would probably make things a lot simpler. It's my hunch that at the moment there are more issues raised about RedBPF not working out of the box with fresh toolchain, and fewer about LLVM mishaps. So we could essentially say, RedBPF 3 only supports LLVM13, RedBPF 2 is LLVM10-12, and we could write instructions for using the appropriate branch.

The only catch here is that I think we're gonna need to start branching major versions so we can backport any necessary security/requested usability features. I also think we should probably draw a line at supporting the LLVM used by the the last edition release (1.56, 2021 right now).

rhdxmr commented 2 years ago

While I was working on this issue, I got to know that llvm-sys can be linked into higher version of LLVM library. For example, llvm-sys-130 can be linked into not only libLLVM-13.so but also libLLVM-14.so. Normally it is permitted to link llvm-sys into higher version of LLVM libraries. If the higher version of LLVM library is known to have incompatibility issues, llvm-sys will block to use it. Or it is likely to happen link time failure while building llvm-sys-130 crate.

quote from llvm-sys documentation:

The build scripts will not enforce this compatibility matrix strictly, permitting compilation against any version of LLVM that is at least as new as the crate target version. This is safe in most cases because the LLVM C API is meant to maintain binary compatibility across releases with the exception of when functions are deprecated and later removed. An incompatible LLVM version will generally fail to compile with a link-time error, rather than cause runtime errors. Where versions are known to break binary compatibility, the build script will prevent compilation.

I expect that it won't be needed to bump up llvm-sys since llvm-sys-130 is likely compatible with libLLVM-14.so. But it will be needed to be checked if some of LLVM C functions would change their parameters, or some of functions would be removed.