runtime: add uprobe_multi support

[Officeyutong]

uprobe_multi is a special type of uprobe, which allows hooking multiple userspace functions in a single attach. This PR adds uprobe_multi support for uprobe_attach_impl, the corresponding example, and update CI

Closes #214

See https://lore.kernel.org/bpf/20230424160447.2005755-1-jolsa@kernel.org/ for details

Our design

In the kernel bpf, the attaching of uprobe_multi were implemented through creating a bpf link, and filling all information (such as pid, function offset, attach cookies) in the link opts. You may find it in bpf_program__attach_uprobe_multi

But in bpftime, all attaches are required to have an attach target (a.k.a perf event), so for uprobe_multi that doesn't give us a perf event, we have a slightly different implementation to the kernel: When creating a bpf link, we doesn't only record configurations from bpf_link_create_opts into the handler, but also do we create some perf events for the uprobe_multi links, and record them in the handler. In this way, we tear down a uprobe_multi into several simple uprobe attach targets, and with a total bpf link. This will not affect the hooking performance.

Main changes

• Update bpf_link_handler to make it support multiple attach targets
• Adapt for multiple attach targets in a single bpf_link

[maxgio92]

Suggested change

	"Trying to instantiate uprobe multi (entry hook), but uretprobe is not registered");
	"Trying to instantiate uprobe multi (entry hook), but uprobe is not registered");

Shouldn't the message be that way?

[maxgio92]

Suggested change

	return std::string("<Frida attach private data addr=") +
	std::to_string(addr);
	return std::string("<Frida attach private data addr=") +
	std::to_string(reinterpret_cast<uintptr_t>(addr)) + ">";

[maxgio92]

Suggested change

	SPDLOG_DEBUG("Attach private data is {}, attach type is ",
	SPDLOG_DEBUG("Attach private data is {}, attach type is {}",

[maxgio92]

Don't we need to check if the attach failed, on attach_id?

[yunwei37]

This branch conflicts with master and still has four non-outdated review threads, including an unchecked attach_id failure path plus message/formatting fixes. The next concrete step is for the author to rebase, address those threads on the rebased code, and request a fresh review; the current head should not be merged.

AI-generated response; a maintainer will review and follow up later