From: Yonghong Song <yonghong.song@linux.dev>
To: Nathan Chancellor <nathan@kernel.org>,
Alan Maguire <alan.maguire@oracle.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
bpf@vger.kernel.org, dwarves@vger.kernel.org
Subject: Re: Many instances of "no BTF func for kfunc ..." and "unresolved symbol ..." from resolve_btfids after pahole 1.32 upgrade
Date: Fri, 2 Oct 2026 10:40:12 +0100 [thread overview]
Message-ID: <efa1ae47-3ccf-4689-9fde-a0294985ccfb@linux.dev> (raw)
In-Reply-To: <20261001224346.GA576434@ax162>
On 10/1/26 3:43 PM, Nathan Chancellor wrote:
> Hi pahole/btf folks,
>
> I have not seen this reported yet, my apologies if it has and I missed
> it. In my LLVM build tests, I am seeing many instances of warnings along
> the lines of
>
> WARN: resolve_btfids: no BTF func for kfunc bpf_xdp_get_xfrm_state in xfrm_state_kfunc_set
> WARN: resolve_btfids: no BTF func for kfunc bpf_xdp_xfrm_state_release in xfrm_state_kfunc_set
> ...
> WARN: resolve_btfids: unresolved symbol bpf_xdp_xfrm_state_release
> WARN: resolve_btfids: unresolved symbol bpf_xdp_get_xfrm_state
> ...
>
> in various configurations across a few different architectures (such as
> arm, powerpc, and riscv). I have attached a full warning log (since it
> is over 3000 lines long) and the configuration that it came from, in
> case they are relevant.
>
> I bisected this to
>
> commit e96290426e180703fb34d904df3772a2389c6df3
> Author: Yonghong Song <yonghong.song@linux.dev>
>
> dwarf_loader: Analyze per-parameter information for true signatures
>
> in pahole 1.32. If there is any other information I can provide or
> patches I can test, I am more than happy to do so.
Could you try the following patch to see whether it solved the issue.
I didn't have environment to test arm, powerpc, riscv, etc.
diff --git a/btf_encoder.c b/btf_encoder.c
index d6b9be6..2f137ee 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c
@@ -2913,7 +2913,7 @@ struct btf_encoder *btf_encoder__new(struct cu *cu, const char *detached_filenam
encoder->tag_kfuncs = conf_load->btf_decl_tag_kfuncs;
encoder->gen_distilled_base = conf_load->btf_gen_distilled_base;
encoder->encode_attributes = conf_load->btf_attributes;
- encoder->true_signature = conf_load->true_signature;
+ encoder->true_signature = conf_load->true_signature && cu->param_loc_supported;
encoder->verbose = verbose;
encoder->has_index_type = false;
encoder->need_index_type = false;
diff --git a/dwarf_loader.c b/dwarf_loader.c
index 1e5363a..9f9b9c9 100644
--- a/dwarf_loader.c
+++ b/dwarf_loader.c
@@ -1518,6 +1518,22 @@ static bool arch__arg_align_two_regs(const GElf_Ehdr *ehdr)
}
}
+/*
+ * Architectures whose argument register mapping has been validated for
+ * matching clang parameter locations and reconstructing true signatures.
+ * Other architectures keep only the basic optimized-out detection.
+ */
+static bool arch__param_loc_supported(const GElf_Ehdr *ehdr)
+{
+ switch (ehdr->e_machine) {
+ case EM_X86_64:
+ case EM_AARCH64:
+ return true;
+ default:
+ return false;
+ }
+}
+
static struct template_type_param *template_type_param__new(Dwarf_Die *die, struct cu *cu, struct conf_load *conf)
{
struct template_type_param *ttparm = tag__alloc(cu, sizeof(*ttparm));
@@ -3777,7 +3793,8 @@ static void function__analyze_parameter_locations(struct function *fn, struct cu
{
struct ftype *ftype = &fn->proto;
struct parameter *pos;
- bool true_sig_enabled = conf->true_signature && ftype->signature_changed;
+ bool true_sig_enabled = cu->param_loc_supported && conf->true_signature &&
+ ftype->signature_changed;
bool check_locations = !cu->producer_clang || ftype->signature_changed;
int reg_idx = 0;
@@ -3785,7 +3802,8 @@ static void function__analyze_parameter_locations(struct function *fn, struct cu
/* Producer is clang and the signature was not changed: match
* each parameter against its expected ABI argument register.
*/
- function__match_clang_parameter_locations(ftype, cu);
+ if (cu->param_loc_supported)
+ function__match_clang_parameter_locations(ftype, cu);
return;
}
@@ -4533,6 +4551,7 @@ static int cu__set_common(struct cu *cu, struct conf_load *conf,
cu->nr_register_params = arch__nr_register_params(&ehdr);
cu->agg_use_two_regs = arch__agg_use_two_regs(&ehdr);
cu->arg_align_two_regs = arch__arg_align_two_regs(&ehdr);
+ cu->param_loc_supported = arch__param_loc_supported(&ehdr);
arch__set_register_params(&ehdr, cu);
return 0;
}
diff --git a/dwarves.h b/dwarves.h
index f3453ed..6b75ece 100644
--- a/dwarves.h
+++ b/dwarves.h
@@ -305,6 +305,7 @@ struct cu {
uint8_t producer_clang:1;
uint8_t agg_use_two_regs:1; /* An aggregate like {long a; long b;} */
uint8_t arg_align_two_regs:1; /* An over-aligned arg starts on an even register */
+ uint8_t param_loc_supported:1; /* Parameter location analysis is validated for this arch */
uint8_t nr_register_params;
int register_params[ARCH_MAX_REGISTER_PARAMS];
int functions_saved;
next prev parent reply other threads:[~2026-10-02 9:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 22:43 Many instances of "no BTF func for kfunc ..." and "unresolved symbol ..." from resolve_btfids after pahole 1.32 upgrade Nathan Chancellor
2026-10-02 9:40 ` Yonghong Song [this message]
2026-10-02 16:25 ` Nathan Chancellor
2026-10-03 8:33 ` Alan Maguire
2026-10-03 8:47 ` Yonghong Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=efa1ae47-3ccf-4689-9fde-a0294985ccfb@linux.dev \
--to=yonghong.song@linux.dev \
--cc=acme@kernel.org \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dwarves@vger.kernel.org \
--cc=eddyz87@gmail.com \
--cc=memxor@gmail.com \
--cc=nathan@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.