Move probe expansion into codegen

[viktormalik]

The previous probe expansion approach tried to minimize the amount of LLVM functions generated by emitting a single function for all probe matches in most cases. While this was efficient, it came with a couple of drawbacks:

• It is necessary to generate a separate LLVM function for each match (e.g. when the probe builtin is used). This leads to having two very similar loops for iterating matches in BPFtrace::add_probe and in CodegenLLVM::visit(Probe) which is quite confusing and hard to maintain.
• libbpf needs one BPF program (i.e. one LLVM function) per probe so if we want to delegate program loading (and possibly attachment) to libbpf (which we do), we cannot use this approach. See [RFC] Probe expansion in codegen #3005 for more details.

This refactors probe expansion by moving most of it into codegen. Overall, we now distinguish two types of probe expansion:

• Full expansion - A separate LLVM function is generated for each match. This is used for most expansions now.
• Multi expansion - Used for k(u)probes when k(u)probe_multi is available. Generates one LLVM function and one BPF program for all matches and attaches the expanded functions via bpf_link_create_opts.

This allows to drop a lot of duplicated code. The expansion for "full" is done in CodegenLLVM::visit(Probe), the expansion for "multi" is done in BPFtrace::add_probe.

A drawback of this approach is that we generate substantially larger ELF objects for expansions of probe types which do not support multi-probes (e.g. kfuncs and tracepoints) as we generate duplicate LLVM functions. This is something we can live with for now since multi-attachment is not the main use-case for these probe types (e.g. attaching to many kfuncs is very slow) and there's usually an alternative to use multi-kprobes. In addition, we will probably add a third expansion type using LLVM symbol aliases but that requires libbpf changes.

One particular area where this refactoring caused problems is unit tests in tests/bpftrace.cpp. Previously, it was sufficient to generate a simple ast::Probe and pass it to BPFtrace::add_probe since that was where most of the expansion was done. Now that the expansion was moved to codegen, we need to do full parser -> field analyser -> clang parser -> semantic analyser -> codegen sequence.

Also, the problem comes with USDT probes as it is not possible to easily mock USDTHelper which is a fully static class. Since we need to override AttachPoint::usdt::num_locations from tests, we allow to do that via a new internal env variable BPFTRACE_TEST_USDT_NUM_LOCATIONS.

Checklist

• Language changes are updated in man/adoc/bpftrace.adoc
• User-visible and non-trivial changes updated in CHANGELOG.md
• The new behaviour is covered by tests

[viktormalik]

Update: I had to drop unit tests for single-wildcard targets for uprobe/USDT added in #2757. The reason is that tests in tests/bpftrace.cpp now run semantic analyser which in turn runs discovery of all running processes on the system for such probes, which is not something that should be run in unit tests (and it cannot be mocked in this case). FWIW, I don't think that those tests would add much value b/c all the code added by #2757 would be replaced by mocks anyways.

[ajor]

Are "full expansion" and "multi expansion" meant to be mutually exclusive? An enum instead of two bools might be clearer/safer if that's the case.

I haven't dug into the cause, but I can trigger a crash on this branch by setting both full and multi expansion to true on a single probe with this script:

kprobe:*:__x64_sys_rea* { print("a") }

[ajor]

Don't we need full expansion for wildcarded executable paths? i.e.:

if (has_wildcard(ap_->target)
  ap_->need_full_expansion = true;

[viktormalik]

In such a case, we do multi-expansion for each expanded path. See BPFtrace::add_probe for details.

[viktormalik]

Are "full expansion" and "multi expansion" meant to be mutually exclusive? An enum instead of two bools might be clearer/safer if that's the case.

Indeed they are, a great suggestion!

I haven't dug into the cause, but I can trigger a crash on this branch by setting both full and multi expansion to true on a single probe with this script:

kprobe:*:__x64_sys_rea* { print("a") }

Nice catch! It should be fixed now.

[viktormalik]

While rebasing onto master, I noticed that uprobe_multi expansion doesn't work with placing uprobes after the funtion prologue. I opened #3173 to track that issue and this PR respects the current behavior (i.e. when uprobe expansion is needed, use kprobe_multi and attach to function entries, otherwise attach after function prologue).

[ajor]

Just a partial review so far - I'll try and get through bpftrace.cpp tomorrow.

I'm not keen on using environment variables to mock behaviour - it runs the risk of something dodgy happening if a user sets the env var at run time. I've recently started thinking about how we can make bpftrace a "trusted compiler" to allow it to be used by a non-root user (for use in containers with BPF token), and for that to work the compiler's behaviour has to be pretty well defined.

How about this as a way of mocking static classes: https://godbolt.org/z/37czorj84

[viktormalik]

I'm not keen on using environment variables to mock behaviour - it runs the risk of something dodgy happening if a user sets the env var at run time. I've recently started thinking about how we can make bpftrace a "trusted compiler" to allow it to be used by a non-root user (for use in containers with BPF token), and for that to work the compiler's behaviour has to be pretty well defined.

It turned out that the only method that we need to mock doesn't need to be static so I made USDTHelper non-static and created MockUSDTHelper which mocks the find method.