All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Alan Maguire <alan.maguire@oracle.com>,
	Nathan Chancellor <nathan@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	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: Sat, 3 Oct 2026 09:47:07 +0100	[thread overview]
Message-ID: <35eb5dec-7b68-420e-8689-0ff91adf5e88@linux.dev> (raw)
In-Reply-To: <9b8b38fd-8f6c-4d2a-a6c1-0886c3a7de24@oracle.com>



On 10/3/26 1:33 AM, Alan Maguire wrote:
> On 02/10/2026 17:25, Nathan Chancellor wrote:
>> Hi Yonghong,
>>
>> On Fri, Oct 02, 2026 at 10:40:12AM +0100, Yonghong Song wrote:
>>> Could you try the following patch to see whether it solved the issue.
>>> I didn't have environment to test arm, powerpc, riscv, etc.
>> Yes, I had to manually apply it but it does appear to resolve this
>> issue. I'll put it through my full build matrix soon but should you send
>> it formally, feel free to add
>>
>>    Tested-by: Nathan Chancellor <nathan@kernel.org> # build
>>
> thanks for doing that. If all looks good on your end with the build matrix
> let me know and we can land it asap. Thanks also for the quick turnaround
> Yonghong!

I just send the fix to the upstream. See
    https://lore.kernel.org/bpf/20261003084357.4185491-1-yonghong.song@linux.dev/

>   
>>> 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-03  8:47 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
2026-10-02 16:25   ` Nathan Chancellor
2026-10-03  8:33     ` Alan Maguire
2026-10-03  8:47       ` Yonghong Song [this message]

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=35eb5dec-7b68-420e-8689-0ff91adf5e88@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.