lkml.org 
[lkml]   [2022]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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
    >

    \
     
     \ /
      Last update: 2022-09-01 04:18    [W:2.647 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site