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;
Message-ID: <bc323d8578d2f6ec580066bab181788b305ae3c3.camel@xry111.site>
Subject: Re: [PATCH v7 0/5] LoongArch: Support toolchain with new relocation
 types
From:   Xi Ruoyao <xry111@xry111.site>
To:     Jinyang He <hejinyang@loongson.cn>,
        Huacai Chen <chenhuacai@kernel.org>,
        WANG Xuerui <kernel@xen0n.name>
Cc:     loongarch@lists.linux.dev, LKML <linux-kernel@vger.kernel.org>,
        Youling Tang <tangyouling@loongson.cn>
Date:   Wed, 31 Aug 2022 16:08:39 +0800
In-Reply-To: <c53303bf-a5d2-098f-8975-efadbe0b2f2e@loongson.cn>
References: <20220830104806.128365-1-xry111@xry111.site>
         <CAAhV-H5bH7xZTWLhqcZ_Bmh=RNaEVBy9523hmj-gTmitqqc8ag@mail.gmail.com>
         <c0ba2e23-5be3-924d-554a-2f10272c05bc@xen0n.name>
         <CAAhV-H7Dz21qRgwkMcJ0SnA9FNDN19E6mpa7C25LUitrO9LGeA@mail.gmail.com>
         <5b87173faeef587a2ffaaa6f58d34e0940231067.camel@xry111.site>
         <c53303bf-a5d2-098f-8975-efadbe0b2f2e@loongson.cn>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.45.2 
MIME-Version: 1.0
Precedence: bulk

On Wed, 2022-08-31 at 14:58 +0800, Jinyang He wrote:
> That's right. Also I am wondering why new toolchain produce .got* in
> kernel. It's unneeded. In the past, gcc create la.global and parsed
> to la.pcrel by gas, and kernel works well. Now it seems we lost this
> feature in gcc. I checked the x86 asm code just now. And some info
> follows,
>=20
> LoongArch64, ./net/ipv4/udp_diag.s, *have reloc hint*
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pcalau12i=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 $r4,%got_pc_hi20(udplite_table)
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ld.d=C2=A0=C2=A0=C2=A0 $=
r4,$r4,%got_pc_lo12(udplite_table)
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 b=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 udp_dump
>=20
> x86_64, ./net/ipv4/udp_diag.s
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 movq=C2=A0=C2=A0=C2=A0 $=
udplite_table, %rdi
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 jmp=C2=A0=C2=A0=C2=A0=C2=
=A0 udp_dump
>=20
> It seems related to -fno-PIE and -cmodel=3Dkernel on x86_64.
> Hope new gcc with this feature now.

On x86_64 -mcmodel=3Dkernel means "all code and data are located in [-
2GiB, 0) range.  We actually don't strictly require a "high" range as
we're mostly a PIC-friendly architecture: note that we use a
pcalau12i/addi.d pair for PIC addressing in [PC-2GiB, PC+2GiB, and a
lu12i.w/addi.d pair for "non-PIC" addressing in [-2GiB, 2GiB), both are
2-insn sequence.

If we can put the main kernel image and the modules in one 2GiB VA
range, we can avoid GOT completely.  But it's not possible for now
because main kernel image is loaded in XKPRANGE but the modules are in
XKVRANGE.  So the best we can achieve before implementing
CONFIG_RELOCATION is using GOT in modules, and avoid GOT in the main
kernel image (with a new code model in GCC, which will benefit both the
kernel and statically linked executables).

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