From: Yonghong Song <yonghong.song@linux.dev>
To: Alan Maguire <alan.maguire@oracle.com>, Jiri Olsa <olsajiri@gmail.com>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
dwarves@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH dwarves v3 1/9] dwarf_loader: Reduce parameter checking with clang DW_AT_calling_convention attr
Date: Mon, 23 Mar 2026 11:32:00 -0700 [thread overview]
Message-ID: <5b57839f-e5e9-4511-aba7-7bea933e9f32@linux.dev> (raw)
In-Reply-To: <0ae2db28-d300-4dd0-ad37-abdb46b96de1@oracle.com>
On 3/23/26 5:56 AM, Alan Maguire wrote:
> On 22/03/2026 17:36, Yonghong Song wrote:
>>
>> On 3/21/26 4:10 PM, Jiri Olsa wrote:
>>> On Fri, Mar 20, 2026 at 12:09:22PM -0700, Yonghong Song wrote:
>>>> Currently every function is checked for its parameters to identify whether
>>>> the signature changed or not. If signature indeed changed, pahole may do
>>>> some adjustment for parameters for true signatures.
>>>>
>>>> In clang, any function with the following attribute
>>>> DW_AT_calling_convention (DW_CC_nocall)
>>>> indicates this function having signature changed.
>>>> pahole can take advantage of this to avoid parameter checking if
>>>> DW_AT_calling_convention is not DW_CC_nocall.
>>>>
>>>> But more importantly, DW_CC_nocall can identify signature-changed functions
>>>> and parameters can be checked one-after-another to create the true
>>>> signatures. Otherwise, it takes more effort to identify whether a
>>>> function has signature changed or not. For example, for funciton
>>>> __bpf_kfunc static void bbr_main(struct sock *sk, u32 ack, int flag,
>>>> const struct rate_sample *rs) { ... }
>>>> and bbr_main() is a callback function in
>>>> .cong_control = bbr_main
>>>> in 'struct tcp_congestion_ops tcp_bbr_cong_ops'.
>>>> In the above bbr_main(...), parameter 'ack' and 'flag' are not used.
>>>> The following are some details:
>>>>
>>>> 0x0a713b8d: DW_TAG_formal_parameter
>>>> DW_AT_location (indexed (0x28) loclist = 0x0166d452:
>>>> [0xffffffff83e77fd9, 0xffffffff83e78016): DW_OP_reg5 RDI
>>>> ...
>>>> DW_AT_name ("sk")
>>>> DW_AT_type (0x0a6f5b2b "sock *")
>>>> ...
>>>>
>>>> 0x0a713b98: DW_TAG_formal_parameter
>>>> DW_AT_name ("ack")
>>>> DW_AT_type (0x0a6f58fd "u32")
>>>> ...
>>>>
>>>> 0x0a713ba2: DW_TAG_formal_parameter
>>>> DW_AT_name ("flag")
>>>> DW_AT_type (0x0a6f57d1 "int")
>>>> ...
>>>>
>>>> 0x0a713bac: DW_TAG_formal_parameter
>>>> DW_AT_location (indexed (0x29) loclist = 0x0166d4a8:
>>>> [0xffffffff83e77fd9, 0xffffffff83e78016): DW_OP_reg2 RCX
>>>> ...
>>>> DW_AT_name ("rs")
>>>> DW_AT_type (0x0a710da5 "const rate_sample *")
>>>> DW_AT_decl_line (1027)
>>>>
>>>> Some analysis for the above dwarf can conclude that the 'ark' and 'flag'
>>>> may be related to RSI and RDX, considering the last one is RCX. Basically this
>>>> requires all parameters are available to collectively decide whether the
>>>> true signature can be found or not. In such case, DW_CC_nocall can make things
>>>> easier as parameter can be checked one after another.
>>>>
>>>> For a clang built bpf-next kernel, in non-LTO setup, the number of kernel functions
>>>> is 69103 and the number of signature changed functions is 875, based on
>>>> DW_AT_calling_convention (DW_CC_nocall)
>>>> indication.
>>> we don't display these stats, right? would be great and probably easy
>>> to count different flags and aggregate them
>> The actual stats will be different depending on kernel code and compiler optimization.
>> But I think I can still count them for each commit so people will know
>> which change caused how much true signature.
>>
> I'll send a patch shortly that does kernel build/compare functions for LLVM/clang [1];
> currently our pahole CI only covers gcc kernel builds. That will show differences
> between pahole next and the current changes in github; that workflow has been handy for
> seeing the effects of pahole changes on the set of vmlinux functions.
>
> We should also look at extending pfunct to do more stats; I've got a few patches which
> get it to support split BTF and add a manual page. It has some basic stats if I
> remember correctly, but it would be nice to extend those at some stage.
>
> [1] https://github.com/alan-maguire/dwarves/actions/runs/23435796365/job/68173414313
Thanks for adding llvm test support in github. This definitely helpful.
I will try to have a few more coverages from llvm side.
>
>>>> Among 875 signature changed functions, after this patch, 495 functions
>>>> can have proper true signatures, mostly due to simple dead argument
>>>> elimination. The number of remaining functions, which cannot get the
>>>> true signature, is 379. They will be addressed in the subsequent commits.
>>> after this change I have more functions added (below) and I checked
>>> few and they seem ok (w/o DW_CC_nocall)
>> Most global functions should be okay. But some global functions
>> esp. if argument is more than 8 byte (struct type), they may be
>> considered as signature change with the current implementation.
>>
>>> jirka
>>>
>>>
>>> acpi_ex_do_debug_object
>>> add_bits
>>> amd_pstate_get_mode_string
>>> dma_alloc_from_contiguous
>>> do_set_pmd
>>> dst_destroy
>>> find_cpio_data
>>> find_microcode_in_initrd
>>> ima_write_policy
>>> insn_init
>>> io_tx_ubuf_complete
>>> ip6_protocol_deliver_rcu
>>> kvm_tdp_mmu_unmap_gfn_range
>>> net_dim_get_def_rx_moderation
>>> net_dim_get_def_tx_moderation
>>> pinctrl_commit_state
>>> string_unescape
>>> syscall_copy_user_array
>>> tdp_mmu_zap_leafs
>>> usb_speed_string
>>> __vlan_find_dev_deep_rcu
>>> __vxlan_fdb_delete
>>> xfs_bmbt_maxrecs
>>> xfs_inobt_maxrecs
>>> ZSTD_buildSequencesStatistics
>>> ZSTD_copyCCtx
>>> ZSTD_findFrameSizeInfo
>>> ZSTD_get1BlockSummary
>>> zstd_get_cparams
>>> ZSTD_getCParams
>>> ZSTD_getCParamsFromCCtxParams
>>> ZSTD_getCParamsFromCDict
>>> ZSTD_getCParams_internal
>>> zstd_get_params
>>> ZSTD_getParams
next prev parent reply other threads:[~2026-03-23 18:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 19:09 [PATCH dwarves v3 0/9] pahole: Encode true signatures in kernel BTF Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 1/9] dwarf_loader: Reduce parameter checking with clang DW_AT_calling_convention attr Yonghong Song
2026-03-21 23:10 ` Jiri Olsa
2026-03-22 17:36 ` Yonghong Song
2026-03-23 12:56 ` Alan Maguire
2026-03-23 18:32 ` Yonghong Song [this message]
2026-03-20 19:09 ` [PATCH dwarves v3 2/9] dwarf_loader: Handle signatures with dead arguments Yonghong Song
2026-03-21 23:10 ` Jiri Olsa
2026-03-22 18:03 ` Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 3/9] dwarf_loader: Refactor initial ret -1 to be macro PARM_DEFAULT_FAIL Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 4/9] dwarf_laoder: Handle locations with DW_OP_fbreg Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 5/9] dwarf_loader: Change exprlen checking condition in parameter__reg() Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 6/9] dwarf_loader: Detect optimized parameters with locations having constant values Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 7/9] dwarf_loader: Handle expression lists Yonghong Song
2026-03-21 23:10 ` Jiri Olsa
2026-03-22 18:33 ` Yonghong Song
2026-03-20 19:09 ` [PATCH dwarves v3 8/9] btf_encoder: Handle optimized parameter properly Yonghong Song
2026-03-20 19:10 ` [PATCH dwarves v3 9/9] tests: Add a few clang true signature tests Yonghong Song
2026-03-23 15:41 ` Alan Maguire
2026-03-23 19:58 ` 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=5b57839f-e5e9-4511-aba7-7bea933e9f32@linux.dev \
--to=yonghong.song@linux.dev \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=arnaldo.melo@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dwarves@vger.kernel.org \
--cc=kernel-team@fb.com \
--cc=olsajiri@gmail.com \
/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