[Proposal] Bump minimum LLVM version to 11

[davemarchevsky]

Currently there is no explicitly-stated minimum version of LLVM that bcc supports linking against. Based on INSTALL.md and @yonghong-song's mailing list response from late 2020, which states

bcc is supposed to work for all major llvm releases since llvm 3.7.

3.7 seems to be the implicit minimum version. 3.7 is from mid-2015.

I propose that we bump the minimum supported version of LLVM to 11 (released late 2020).

Why?

bcc is one of the more widely-deployed projects in the BPF ecosystem, the tools specifically are many folks' introduction to BPF. In order to keep bcc working in as many environments as possible with minimum fuss we've historically tried to support a variety of older LLVMs. There are a few reasons why I think this is no longer the best path forward:

• Working around LLVM API changes across so many versions is tedious at best and at worst actively prevents progress. Sprinkling some preprocessor conditionals is not the end of the world, generally LLVM APIs and functionality we rely on don't change too much across versions. This isn't the case currently, though: my "Keep track of BPF progs using function instead of section" refactor won't work on older LLVMs due to an implementation difference. Landing that refactor is a necessary part of the "bcc -> libbpf" loader conversion project, which will result in an easier-to-maintain bcc with access to more cutting-edge libbpf features (e.g. global variables).
• Old LLVMs can produce inefficient or broken BPF bytecode. Although a C compiler from 2015 is not usually considered 'old', there's been significant work on the BPF backend since then, including many logic fixes to ensure that the BPF verifier will accept the generated bytecode. BPF maintainers have mentioned hearing from confused users whose BPF programs - generated by bcc - are rejected by the verifier, with upgrading to a more recent LLVM fixing the issue. This results in frustration and wasted time on the users' part ("I'm just trying to get this simple thing to work") and maintainers ("Didn't we fix this bad bytecode generation two years ago?").

Why Now?

Similar to #3682, I feel that we've reached an inflection point where the drag of continuing to support old LLVMs is no longer worth it. Conversations with upstream BPF folks have convinced me that the second bullet above is more of an issue than I previously thought.

What needs to be done?

We need to update bcc packages on various distros, either in-tree (e.g. snap dir) or not, to list the llvm 11 as the minimum required version.

Need to confirm that Github Actions test workflows are testing with 11+ (preferably each major release will be tested). Currently ubuntu test container is using 11, fedora is using 12.

Then can remove LLVM version checks for older versions

[yonghong-song]

@rupran @bluca @brendangregg Please let us know if you see any issues with this minimum llvm version 11 requirement.

[bluca]

no issue from my point of view

[rupran]

Same from me, libdebuginfod support should work just fine.

[yonghong-song]

Thanks @bluca and @rupran for confirmation!