Re: [PATCH bpf-next v5 14/21] libbpf: Resolve the compiler's _Unwind_Resume to the kernel's kfunc

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Wed Sep 23, 2026 at 6:59 AM CEST, Yonghong Song wrote:
> LLVM terminates a cleanup landing pad with a call to _Unwind_Resume: the
> base unwind ABI's entry point for carrying an unwind on once a frame's
> cleanups have run. The kernel provides that terminator as a kfunc, but
> not under that name: claiming _Unwind_Resume in the kernel's own symbol
> table, for a function whose body never runs, would be needlessly confusing,
> so it is called bpf_unwind_resume.
>
> Both load paths take the detour. A direct load resolves the name against
> the kernel's BTF while libbpf runs. A light skeleton instead writes the
> name into the loader program's blob of bytes, for that program to resolve
> when it runs, so the name recorded there has to be translated as well.
>
> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
> ---
>  tools/lib/bpf/libbpf.c | 23 ++++++++++++++++++-----
>  1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index cd1ea1bb53cb..2d0081784445 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -8379,6 +8379,16 @@ static void fixup_verifier_log(struct bpf_program *prog, char *buf, size_t buf_s
>  	}
>  }
>
> +/*
> + * LLVM terminates a cleanup landing pad with a call to _Unwind_Resume, the
> + * base unwind ABI's entry point for carrying an unwind on once a frame's
> + * cleanups have run. The kernel knows it as bpf_unwind_resume.
> + */
> +static const char *kern_extern_name(const char *name)
> +{
> +	return strcmp(name, "_Unwind_Resume") ? name : "bpf_unwind_resume";
> +}
> +
>  static int bpf_program_record_relos(struct bpf_program *prog)
>  {
>  	struct bpf_object *obj = prog->obj;
> @@ -8395,12 +8405,12 @@ static int bpf_program_record_relos(struct bpf_program *prog)
>  				continue;
>  			kind = btf_is_var(btf__type_by_id(obj->btf, ext->btf_id)) ?
>  				BTF_KIND_VAR : BTF_KIND_FUNC;
> -			bpf_gen__record_extern(obj->gen_loader, ext->name,
> +			bpf_gen__record_extern(obj->gen_loader, kern_extern_name(ext->name),
>  					       ext->is_weak, !ext->ksym.type_id,
>  					       true, kind, relo->insn_idx);
>  			break;
>  		case RELO_EXTERN_CALL:
> -			bpf_gen__record_extern(obj->gen_loader, ext->name,
> +			bpf_gen__record_extern(obj->gen_loader, kern_extern_name(ext->name),
>  					       ext->is_weak, false, false, BTF_KIND_FUNC,
>  					       relo->insn_idx);
>  			break;
> @@ -8876,17 +8886,20 @@ static int bpf_object__resolve_ksym_func_btf_id(struct bpf_object *obj,
>  	struct module_btf *mod_btf = NULL;
>  	const struct btf_type *kern_func;
>  	struct btf *kern_btf = NULL;
> +	const char *local_name, *kern_name;
>  	int ret;
>
>  	local_func_proto_id = ext->ksym.type_id;
>
> -	kfunc_id = find_ksym_btf_id(obj, ext->essent_name ?: ext->name, BTF_KIND_FUNC, &kern_btf,
> -				    &mod_btf);
> +	local_name = ext->essent_name ?: ext->name;
> +	kern_name = kern_extern_name(local_name);
> +
> +	kfunc_id = find_ksym_btf_id(obj, kern_name, BTF_KIND_FUNC, &kern_btf, &mod_btf);

Compiler doesn't directly emit it in .ksyms section, right? How does this work
in practice? It's a bit confusing and not clear from the commit log.

> [...]