[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2bd6ae20-ec56-c1a2-c5dd-e8c978a376d3@loongson.cn>
Date: Fri, 7 Jun 2024 15:14:41 +0800
From: Jinyang He <hejinyang@...ngson.cn>
To: Xi Ruoyao <xry111@...111.site>, Nathan Chancellor <nathan@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Cc: Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>,
Tiezhu Yang <yangtiezhu@...ngson.cn>,
Nick Desaulniers <ndesaulniers@...gle.com>, Bill Wendling
<morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>,
Youling Tang <tangyouling@...inos.cn>, loongarch@...ts.linux.dev,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
mengqinggang@...ngson.cn, cailulu@...ngson.cn, wanglei@...ngson.cn,
luweining@...ngson.cn, Yujie Liu <yujie.liu@...el.com>,
Heng Qi <hengqi@...ux.alibaba.com>, Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH] loongarch: Only select HAVE_OBJTOOL and allow ORC
unwinder if the inline assembler supports R_LARCH_{32,64}_PCREL
On 2024-06-07 13:42, Xi Ruoyao wrote:
> On Thu, 2024-06-06 at 10:10 +0800, Jinyang He wrote:
>> What I just confused is that there is no ".cfi_*"
>> in the eplogue by clang, which may cause wrong backtrace if gdb set
>>
>> breakpoint there and backtrace. (But this is out of this topic.)
> I don't think it'll cause wrong backtrace. The real assemble code has
> restored the registers and missing .cfi_restore will just make unwinder
> restore them again. There are redundant works but not breakages.
$ cat hello.c:
extern void __attribute__((noinline)) foo() {}
int main() {
foo();
return (int)(long)__builtin_frame_address(0);
}
$ clang hello.c -S -g -o hello.s -O0 -fPIC
$ cat hello.s:
[...]
addi.d $sp, $sp, -32
.cfi_def_cfa_offset 32
st.d $ra, $sp, 24 # 8-byte Folded Spill
st.d $fp, $sp, 16 # 8-byte Folded Spill
.cfi_offset 1, -8
.cfi_offset 22, -16
addi.d $fp, $sp, 32
.cfi_def_cfa 22, 0
move $a0, $zero
st.w $a0, $fp, -20
.Ltmp2:
.loc 0 3 3 prologue_end # hello.c:3:3
bl %plt(foo)
.loc 0 4 21 # hello.c:4:21
move $a0, $fp
.loc 0 4 3 is_stmt 0 # hello.c:4:3
addi.w $a0, $a0, 0
ld.d $fp, $sp, 16 # 8-byte Folded Reload
<use gdb and set break ponint there>
ld.d $ra, $sp, 24 # 8-byte Folded Reload
.loc 0 4 3 epilogue_begin # hello.c:4:3
addi.d $sp, $sp, 32
ret
[...]
So how unwinder do if we <use gdb and set break ponint there>? I think
if we not give ".cfi_restore 22" or others info, it will consider
1) the $ra is in cfa-8
2) the cfa is $fp
So it will get $ra by $ra = *(long*)($fp-8). So it may unwind failed
because $fp has been restored and not the CFA now.
> For objtool the main difference seems a thing explained in
> https://maskray.me/blog/2020-11-08-stack-unwinding by Fangrui:
>
> Note: on RISC-V and LoongArch, the stack slot for the previous frame
> pointer is stored at fp[-2] instead of fp[0]. See [Consider
> standardising which stack slot fp points
> to](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/18)
> for the RISC-V discussion.
In most cases the $fp is saved at cfa-16. But for va args, something
becomes different at LoongArch (I do not know the case of riscv), the
$fp isn't saved at cfa-16. (e.g. printk?)
> So perhaps we just need to code a constant named "PREV_BP_OFFSET"
Can you give some detail?
> or
> something in arch/ and use it in update_cfi_state() instead of fully re-
> implement the entire function?
I feel that the update_cfi_state should be arch specific. I believe
that some logic can be reused, but each arch may have its own logic.
Thanks,
Jinyang
Powered by blists - more mailing lists