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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox