Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [PATCH 1/3] LoongArch: tools: Add relocs tool support
To:     Xi Ruoyao <xry111@xry111.site>, Jinyang He <hejinyang@loongson.cn>,
        Huacai Chen <chenhuacai@kernel.org>
References: <1662113335-14282-1-git-send-email-tangyouling@loongson.cn>
 <1662113335-14282-2-git-send-email-tangyouling@loongson.cn>
 <c9880165f0355fc3be3ec23153b43ad33e558b5d.camel@xry111.site>
 <4df8a26c49a35c1fce36d80c370f738fa71a2bef.camel@xry111.site>
 <f0e77716-9533-724a-2ea9-86bc5b52066c@loongson.cn>
 <78a4a6b0970c309daa336a2329e69d28df486552.camel@xry111.site>
 <fffdd2ac-4ba6-8eb3-f269-b22a3d9c32f6@loongson.cn>
 <0b2d115c42ff6cb9b8c65d852ec2f0746ca6e8d9.camel@xry111.site>
Cc:     linux-kernel@vger.kernel.org, loongarch@lists.linux.dev,
        Xuerui Wang <kernel@xen0n.name>,
        Jiaxun Yang <jiaxun.yang@flygoat.com>
From:   Youling Tang <tangyouling@loongson.cn>
Message-ID: <d852f590-95b4-3fd1-924a-68c0a6bb1b1b@loongson.cn>
Date:   Mon, 5 Sep 2022 10:52:42 +0800
User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <0b2d115c42ff6cb9b8c65d852ec2f0746ca6e8d9.camel@xry111.site>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi, Ruoyao

On 09/04/2022 12:53 AM, Xi Ruoyao wrote:
> 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
>

Thank you very much.

After applying the above two patches and the following modifications,
the relocation can be successful after removing the
apply_r_loongarch_la_rel (for la.abs relocation) implementation. I
tested it in the qemu environment.

--- a/arch/loongarch/kernel/head.S
+++ b/arch/loongarch/kernel/head.S
@@ -113,9 +113,11 @@ SYM_CODE_START(smpboot_entry)
         li.d            t0, CSR_DMW1_INIT       # CA, PLV0
         csrwr           t0, LOONGARCH_CSR_DMWIN1

-       la.abs          t0, 0f
-       jr              t0
-0:
+       li.d            t0, CACHE_BASE
+       pcaddi          t1, 0
+       or              t0, t0, t1
+       jirl            zero, t0, 0xc

Youling.

> 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 */
>
>