On 8/8/26 8:11 PM, Dave Young wrote:
Hi Tao,
On 8/6/26 8:16 AM, Tao Liu wrote:
> Previously ORC_REG_SP and ORC_REG_PREV_SP will depend on kernel version
> for their value, however this is fragile since distributions will
> backport the upstream patch to a lower kernel version, thus break the
> version assumption.
>
> This patch fixes by checking the value of ORC_REG_PREV_SP, which can be
> get from orc_fp_entry. ORC_REG_PREV_SP's value can work as the indicator
> of whether the current kernel have applied the upstream patch 1735858caa4b
> ("objtool/x86: Reorder ORC register numbering").
>
> Fixes: d0ee428664f9 ("x86_64: Fix "bt" command to use correct ORC
register
> values on Linux 7.1 and later")
>
> Signed-off-by: Tao Liu <ltao(a)redhat.com>
> ---
> v3 -> v2: Remove data type query of orc_fp_entry, just use kernel_orc_entry_6_4
> which already contained in crash utility for bp_reg offset resolving.
> ---
> x86_64.c | 32 +++++++++++++++++++++++++-------
> 1 file changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/x86_64.c b/x86_64.c
> index 55648697baf3..d192f3bcdd20 100644
> --- a/x86_64.c
> +++ b/x86_64.c
> @@ -6661,6 +6661,9 @@ x86_64_ORC_init(void)
> NULL
> };
> struct ORC_data *orc;
> + struct gnu_request request, *req;
> + ulong value = 0;
> + req = &request;
>
> MEMBER_OFFSET_INIT(inactive_task_frame_bp, "inactive_task_frame",
"bp");
> MEMBER_OFFSET_INIT(inactive_task_frame_ret_addr, "inactive_task_frame",
"ret_addr");
> @@ -6736,13 +6739,28 @@ x86_64_ORC_init(void)
> if (orc->has_signal && !orc->has_end)
> machdep->flags |= ORC_6_4;
>
> - /* See kernel commit 1735858caa4b */
> - if (THIS_KERNEL_VERSION >= LINUX(7,1,0)) {
> - ORC_REG_SP = 3;
> - ORC_REG_PREV_SP = 8;
> - } else {
> - ORC_REG_SP = 5;
> - ORC_REG_PREV_SP = 1;
> + /* Try get ORC_REG_(PREV)_SP */
> + ORC_REG_SP = 5;
> + ORC_REG_PREV_SP = 1;
How about use the newere values as default, and check the symbol data and set them as old
ones if needed?
Hmm, if change the order, the orc_fp_entry could not exist since it was introduced in
2025. Ok, unless you have some smarter idea, the patch looks good, please ignore the
above comment.
Reviewed-by: Dave Young <yangrr.2009(a)tsinghua.org.cn>
Thanks