Add support for LLVM 14 (Rust 1.60)

[rsdy]

The latest stable is now built against LLVM14.

[nbaksalyar]

This is blocked by llvm-sys: https://gitlab.com/taricorp/llvm-sys.rs/-/issues/30

[rsdy]

Note that I'm probably going to use this upgrade opportunity to deprecate support for LLVM versions <13. RedBPF 3 will only support 13 +14.

[nbaksalyar]

I submitted a patch for llvm-sys and my fork can be used to start implementing support for llvm14 in redbpf. I can give it a try. :)

[b0bleet]

Hi is there any update for LLVM 14 support?
@nbaksalyar

[rsdy]

@b0bleet I'm a bit cautious on merging this, but should be functional. If you're keen on testing, that would be super helpful. The biggest obstacle in mergin #316 is fixing the CI.

[DerekStrickland]

Hi @rsdy . I've got this PR staged to upgrade the build images to llvm14. CI for the images is passing here. I might have made some invalid assumptions, or upgraded too much, so just let me know, and I will revise.

[DerekStrickland]

Sorry this has stalled a bit. I started a new job recently. Hoping to get back to this later this week. When I left off I found a couple of more changes to the upstream build-images repo that I'll need to submit around pinning linux header versions on some distros.

Also, I started running into variable kernel implementations and was struggling to find the right mechanism to dynamically change the implementation based on what the kernel supports as documented in this Rust Forum thread. Unfortunately, it seems like there are multiple inconsistencies based on distro. If there is already a way that you are handling this, please feel free to point me towards the right example code. Otherwise, I'll take a pass at it as best as I can devise.

[rsdy]

@DerekStrickland thanks a lot for your work, and bringing this to the Rust forum. I think the combination of the two approaches brought up in the thread is probably the correct thing to do.

I can't take a look in depth at the code right now, but https://github.com/BLAKE3-team/BLAKE3 pops into mind, where a significant amount of CPU feature detection happens in build.rs. Setting those cfg variables through the build file allows subsequent checks on them while building the crate. I should probably add that some heuristics translate feature-flags into internal cfg variables, too.

We should have all the code that parses Linux kernel versions that would allow you to toggle necessary feature tags. I should be able to get more in-depth look towards the end of the week if you think that's helpful.

[DerekStrickland]

Thanks for the guidance. I'll take a look at the link you provided after Wednesday, and reach back out if I have further questions, or something to review.