Received-SPF: pass (google.com: domain of linux-kernel+bounces-215803-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <a97cd0f2e2cac10253d6b5cdd0ace3db3b220535.camel@xry111.site>
Subject: Re: [PATCH] loongarch: Only select HAVE_OBJTOOL and allow ORC
 unwinder if the inline assembler supports R_LARCH_{32,64}_PCREL
From: Xi Ruoyao <xry111@xry111.site>
To: Huacai Chen <chenhuacai@kernel.org>
Cc: Jinyang He <hejinyang@loongson.cn>, Nathan Chancellor
 <nathan@kernel.org>,  Peter Zijlstra <peterz@infradead.org>, WANG Xuerui
 <kernel@xen0n.name>, Tiezhu Yang <yangtiezhu@loongson.cn>,  Nick
 Desaulniers <ndesaulniers@google.com>, Bill Wendling <morbo@google.com>,
 Justin Stitt <justinstitt@google.com>,  Youling Tang
 <tangyouling@kylinos.cn>, loongarch@lists.linux.dev,
 linux-kernel@vger.kernel.org,  llvm@lists.linux.dev,
 mengqinggang@loongson.cn, cailulu@loongson.cn,  wanglei@loongson.cn,
 luweining@loongson.cn, Yujie Liu <yujie.liu@intel.com>,  Heng Qi
 <hengqi@linux.alibaba.com>, Tejun Heo <tj@kernel.org>
Date: Sat, 15 Jun 2024 16:53:39 +0800
In-Reply-To: <CAAhV-H5Wz=U4kbX+tXt1qoCr6RaEDkzZXV7B=tgU_8o+X-NtVQ@mail.gmail.com>
References: <20240604150741.30252-1-xry111@xry111.site>
	 <20240605054328.GA279426@thelio-3990X>
	 <b55b8cb2c52f2c3701c83353586130b8dc237ee2.camel@xry111.site>
	 <20240605062548.GF279426@thelio-3990X>
	 <f8ef61773b0119b8573fc0fed9ad0a8b43061efd.camel@xry111.site>
	 <444ec2031ef6ca016cbfa8dfedc51bddc8529ba7.camel@xry111.site>
	 <ada035690e446909c3cdbf9a43a92def96020615.camel@xry111.site>
	 <82b7e6ea-c2cb-6364-ebe9-bff928028408@loongson.cn>
	 <1c132209a612e2e8953f0b458fc01853120db9a9.camel@xry111.site>
	 <2bf11cd2-8449-acda-f5ad-659c38cb018e@loongson.cn>
	 <96a2e8a80c06772b64fcbdba42e1dae2d68a53a7.camel@xry111.site>
	 <2bd6ae20-ec56-c1a2-c5dd-e8c978a376d3@loongson.cn>
	 <329dac82e09dfc75e77ae93ebbeacdec1dc9ff7f.camel@xry111.site>
	 <CAAhV-H5Wz=U4kbX+tXt1qoCr6RaEDkzZXV7B=tgU_8o+X-NtVQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.2 
Precedence: bulk
MIME-Version: 1.0

On Sat, 2024-06-15 at 16:45 +0800, Huacai Chen wrote:
> Hi, Ruoyao and Jinyang,
>=20
> On Fri, Jun 7, 2024 at 4:29=E2=80=AFPM Xi Ruoyao <xry111@xry111.site> wro=
te:
> >=20
> > On Fri, 2024-06-07 at 15:14 +0800, Jinyang He wrote:
> > > > =C2=A0=C2=A0=C2=A0=C2=A0 Note: on RISC-V and LoongArch, the stack s=
lot for the previous frame
> > > > =C2=A0=C2=A0=C2=A0=C2=A0 pointer is stored at fp[-2] instead of fp[=
0]. See [Consider
> > > > =C2=A0=C2=A0=C2=A0=C2=A0 standardising which stack slot fp points
> > > > =C2=A0=C2=A0=C2=A0=C2=A0 to](https://github.com/riscv-non-isa/riscv=
-elf-psabi-doc/issues/18)
> > > > =C2=A0=C2=A0=C2=A0=C2=A0 for the RISC-V discussion.
> > >=20
> > > 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?)
> >=20
> > Oops indeed.=C2=A0 Even with a very simple case:
> >=20
> > int sum(int a, int b) {
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return a + b;
> > }
> >=20
> > with -fno-omit-frame-pointer we get:
> >=20
> > sum:
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 addi.d=C2=A0 $r3,$r3,-16
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 st.d=C2=A0=C2=A0=C2=A0 $r22,=
$r3,8
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 addi.d=C2=A0 $r22,$r3,16
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ld.d=C2=A0=C2=A0=C2=A0 $r22,=
$r3,8
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 add.w=C2=A0=C2=A0 $r4,$r4,$r=
5
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 addi.d=C2=A0 $r3,$r3,16
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 jr=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 $r1
> >=20
> > So for leaf functions (where we don't save $ra) $fp is saved at cfa-8.
> >=20
> > > 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.
> >=20
> > I agree it now.
> What is the conclusion about the clang part now? And for the original
> -mno-thin-add-sub problem, do you have some way to fix it in the root?
> I think we needn't rush, there are some weeks before 6.10 released.

To me for now we should just make OBJTOOL and ORC depend on BROKEN and
backport to stable...

Even if we can fix both the -mno-thin-add-sub problem and the frame
pointer problem in these weeks, they'll be some nontrivial large change
and improper to backport.  Thus we have to admit objtool doesn't really
work for old releases and mark it broken.


--=20
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University