[Crash-utility] Re: [PATCH v3] x86_64: Make ORC_REG_SP and ORC_REG_PREV_SP independent from kernel version

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&gt; >> --- >> 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&gt; Thanks