public inbox for dwarves@vger.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Alan Maguire <alan.maguire@oracle.com>,
	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: Sun, 22 Mar 2026 10:36:01 -0700	[thread overview]
Message-ID: <2c9260b9-0eb3-416b-a75f-f33f37be6b63@linux.dev> (raw)
In-Reply-To: <ab8lWhTT8LZGbtQs@krava>



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.

>
>> 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


  reply	other threads:[~2026-03-22 17:36 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 [this message]
2026-03-23 12:56       ` Alan Maguire
2026-03-23 18:32         ` Yonghong Song
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=2c9260b9-0eb3-416b-a75f-f33f37be6b63@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