[RFC] freplace removal

[atenart]

We discussed removing the use of freplace and instead statically compile hooks into the probes. This is based on top of #464 and the last patch only is about $topic. The goal is only to show what this change could look like.

Notes:

• The Hook object containing the hooks' instructions was repurposed to be an enum about which hooks to enable.
• The ovs collector wasn't converted.
• The USDT part wasn't converted. I'm thinking this part could actually be done a bit differently as there is no point of having common hooks shared between collectors. Instead a probe could be build per-collector.

Overall this requires a bit more maintenance but it doesn't look that bad.

Thoughts?

[atenart]

I added an initial (incomplete, eg. retval in fexit) support for fentry/fexit to show what it'll likely look like.

The main advantage is fexit probes have access the to function's input parameters, which helps not requiring the extra dance we have in the kretprobe implementation. Other than that kprobe is superior to fentry for us as it supports "loading once attaching to many", and (I have local patches for that) support for attaching multiple probes at once (which speed up things greatly). I saw some activity to improve fentry in that regard upstream but that isn't ready yet and I'm not sure what will be the extend of the improvements.

As a summary, with those changes, the preferred probe types in Retis would be:

• raw_tracepoint for key probes that must be stable over time, unless
• they are marked as noinline in which case kprobe is superior
• fexit for working on the returned values
• kprobe for all other, including user defined, probes

[amorenoz]

Just for reference, we've discussed this and there is a potential problem with this approach:

Originally, filter code was freplaced. This is the clean and elegant approach of injecting the filter code. However, in order to support older kernels (RHEL 8.4) that did not support pointer arguments, we moved to the current approach that intercepts the program registration and modifies the program on the fly.

LIBBPF_API int libbpf_register_prog_handler (const char *sec, enum bpf_prog_type prog_type, enum bpf_attach_type exp_attach_type, const struct libbpf_prog_handler_opts *opts)

This API was introduced because perf needed it and has received some pushback. Perf no longer needs it and there is a chance it gets deprecated, in which case we would be left with:

• Manually modify the programs in rust (before libbpf).
• Going back to freplace and not support native filtering fentry/fexit. Fentry could be replaced by kprobes and fexits could use the trick we do for kretprobes then what's the point?

[atenart]

Le'ts also note (as per my understanding) having fexit support is desired for multiple reasons (easy access to fct arguments, filtering, etc).

[vlrpl]

I guess we should be fine if this turns from __always_inline to __noinline keeping it static.
The advantage would be not sharing the stack with the main prog (512 bytes are not that much).

[vlrpl]

alternatively, and probably better, we could avoid inlining in DEFINE_HOOK().

[vlrpl]

maybe fx for this one?
fe is common between fentry and fexit :)

[vlrpl]

just a general comment here.
I was thinking, assuming we want to explore different approaches, that this is where libbpf linker could help (Linker in libbpf-rs).
An idea could be having our main programs normally calling __weak functions and relink the ones we intend to include.
Basically, this simply moves relinking. The only difference would be precedence (but nothing prevents us from enforcing it if needed).
Ideally filtering would use this as well, but ELF generation is required and we don't have it (but even in this case, nothing prevents us from implementing it, just needs :)