Re: [PATCH 1/3] LoongArch: tools: Add relocs tool support

From: Xi Ruoyao <xry111@xry111.site>
To: Jinyang He <hejinyang@loongson.cn>,
	Youling Tang <tangyouling@loongson.cn>,
	Huacai Chen <chenhuacai@kernel.org>
Cc: linux-kernel@vger.kernel.org, loongarch@lists.linux.dev,
	Xuerui Wang <kernel@xen0n.name>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>
Subject: Re: [PATCH 1/3] LoongArch: tools: Add relocs tool support
Date: Sun, 04 Sep 2022 00:53:34 +0800	[thread overview]
Message-ID: <0b2d115c42ff6cb9b8c65d852ec2f0746ca6e8d9.camel@xry111.site> (raw)
In-Reply-To: <fffdd2ac-4ba6-8eb3-f269-b22a3d9c32f6@loongson.cn>

On Sun, 2022-09-04 at 00:23 +0800, Jinyang He wrote:
> On 2022/9/3 18:49, Xi Ruoyao wrote:
> 
> > On Sat, 2022-09-03 at 09:57 +0800, Youling Tang wrote:
> > > > > Unlike (pre-r6) MIPS, LoongArch has a complete support for PIC, and
> > > > > currently LoongArch toolchain always produces PIC (except, if -Wa,-mla-
> > > > > {local,global}-with-abs or la.abs macros are used explicitly).
> > > > > 
> > > > > So would it be easier to review and correct the uses of "la.abs" in the
> > > > > code, and make the main kernel image a real PIE?  Then we can load it
> > > > > everywhere w/o any need to do relocation at load time.
> > > At the beginning I also wanted to make the main kernel image a real PIE
> > > and tried it, some of the "la.abs" can be modified, but I encountered
> > > difficulties in modifying the  exception handling code part, the kernel
> > > will not  boot after modification :(, I will continue to work hard try.

> > I just tried the same thing and get the same result :(.  Will spend
> > several hours reading the LoongArch manual about exception...

The reason is the handler code is not executed in linker address, but
copied elsewhere.  Then PC-relative offset is broken.  I managed to work
around it by creating a trampoline and jump into the handler, instead of
copy the handler code.  Then I could remove most "la.abs" occurrence
(except two in kernel entry point, which seem deliberately used):

- https://github.com/xry111/linux/commit/56a433f
- https://github.com/xry111/linux/commit/48203e6

Using the trampoline in handler table will definitely lead to sub-
optimal performance. I just use it as a proof-of-concept. Later we may
use some assembler trick to generate hard-coded handler table with
correct PC-relative offsets.

> The following ideas are based on experience, without validation. Patches
> show that three types of relocation are needed to be done.
> 1, GOT is generated by toolchain, so  I think eliminating them by 
> toolchain is better.

https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600797.html

I stop to read the mail here because it's 00:52 AM now :).

> 2, Ex_table is generated but striped relocation info. We can plays pcrel
> way to resolve this problem. One of ways like follows, (pseudo-code)

/* snip */

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