Messages in this thread | | | From | Huacai Chen <> | Date | Thu, 1 Sep 2022 10:17:01 +0800 | Subject | Re: [PATCH v7 0/5] LoongArch: Support toolchain with new relocation types |
| |
Hi, Ruoyao,
On Wed, Aug 31, 2022 at 11:15 PM Xi Ruoyao <xry111@xry111.site> wrote: > > On Wed, 2022-08-31 at 22:40 +0800, Huacai Chen wrote: > > On Wed, Aug 31, 2022 at 4:09 PM Xi Ruoyao <xry111@xry111.site> wrote: > > > > > > 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, > > > > > > > > LoongArch64, ./net/ipv4/udp_diag.s, *have reloc hint* > > > > pcalau12i $r4,%got_pc_hi20(udplite_table) > > > > ld.d $r4,$r4,%got_pc_lo12(udplite_table) > > > > b udp_dump > > > > > > > > x86_64, ./net/ipv4/udp_diag.s > > > > movq $udplite_table, %rdi > > > > jmp udp_dump > > > > > > > > It seems related to -fno-PIE and -cmodel=kernel on x86_64. > > > > Hope new gcc with this feature now. > > > > > > On x86_64 -mcmodel=kernel 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). > > > Emmm, can you implement this new code model in the near future? > > I have a plan to make our toolchain addressing the symbols better: > > (1) https://sourceware.org/pipermail/binutils/2022-August/122682.html. > This change will allow the linker to link a main executable image > (dynamically linked or statically linked, PIE or non-PIE, kernel or > userspace) with R_LARCH_COPY instead of GOT. (Note that R_LARCH_COPY > will not show up in the kernel because we don't link to shared objects, > but GOT will be gone.) > > (2) Change GCC to stop using GOT unless -fPIC. (Technically it's a one- > line change.) > > (3) In kernel, for main kernel image the default of toolchain will be > good enough (no GOT). For modules we have two options: > > (a) get rid of XKPRANGE. > (b) force -mcmodel=extreme globally. > (c) use -Wl,nocopyreloc to produce GOT. > > (a) is the best, the performance of (b) and (c) will be worse than (a). > I'm not sure which one in (b) and (c) is better, but as (a) will be the > final solution we can just choose one in (b) and (c) "randomly" for now. > > I don't want to add a new code model now, because if (1) works fine > we'll not need a new code model. (1) is also the most tricky step in > the plan (I've sent the patch but not sure if it's completely correct), > (2) and (3) should be trivial. Now all global variable accesses are via got, I think the performance may be much worse than before when we didn't use explicit-relocs. I don't know whether "a new code model" or your "(1)(2)(3)" is easier to implement, but I think it is better to solve the performance issue before 6.1-rc1.
Huacai
> -- > Xi Ruoyao <xry111@xry111.site> > School of Aerospace Science and Technology, Xidian University >
| |