BPF List
 help / color / mirror / Atom feed
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;


  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