linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>
Subject: Re: [PATCH v7 0/5] LoongArch: Support toolchain with new relocation types
Date: Wed, 31 Aug 2022 16:08:39 +0800	[thread overview]
Message-ID: <bc323d8578d2f6ec580066bab181788b305ae3c3.camel@xry111.site> (raw)
In-Reply-To: <c53303bf-a5d2-098f-8975-efadbe0b2f2e@loongson.cn>

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).

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

  reply	other threads:[~2022-08-31  8:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 10:48 [PATCH v7 0/5] LoongArch: Support toolchain with new relocation types Xi Ruoyao
2022-08-30 10:48 ` [PATCH v7 1/5] LoongArch: Add CONFIG_AS_HAS_EXPLICIT_RELOCS Xi Ruoyao
2022-08-30 10:48 ` [PATCH v7 2/5] LoongArch: Adjust symbol addressing for CONFIG_AS_HAS_EXPLICIT_RELOCS Xi Ruoyao
2022-08-30 10:48 ` [PATCH v7 3/5] LoongArch: Define ELF relocation types added in v2.00 ABI Xi Ruoyao
2022-08-30 10:48 ` [PATCH v7 4/5] LoongArch: Support PC-relative relocations in modules Xi Ruoyao
2022-08-30 12:59   ` kernel test robot
2022-08-30 10:48 ` [PATCH v7 5/5] LoongArch: Support R_LARCH_GOT_PC* " Xi Ruoyao
2022-08-30 13:05 ` [PATCH v7 0/5] LoongArch: Support toolchain with new relocation types Huacai Chen
2022-08-30 14:48   ` Xi Ruoyao
2022-08-30 16:37   ` WANG Xuerui
2022-08-31  5:44     ` Huacai Chen
2022-08-31  6:10       ` Xi Ruoyao
2022-08-31  6:58         ` Jinyang He
2022-08-31  8:08           ` Xi Ruoyao [this message]
2022-08-31 14:40             ` Huacai Chen
2022-08-31 15:14               ` Xi Ruoyao
2022-09-01  2:17                 ` Huacai Chen
2022-09-01  2:26                   ` Xi Ruoyao
2022-09-06  0:32                   ` Xi Ruoyao
2022-09-06  1:52                     ` Huacai Chen
2022-09-06  4:26                       ` Xi Ruoyao
2022-09-06  4:43                         ` Huacai Chen
2022-09-06  5:01                           ` Xi Ruoyao
2022-09-06  5:57                             ` Huacai Chen
2022-09-06  7:18                           ` Ard Biesheuvel
2022-09-06  8:20                             ` Huacai Chen
2022-09-06  8:59                               ` Huacai Chen
2022-09-06 10:16                                 ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc323d8578d2f6ec580066bab181788b305ae3c3.camel@xry111.site \
    --to=xry111@xry111.site \
    --cc=chenhuacai@kernel.org \
    --cc=hejinyang@loongson.cn \
    --cc=kernel@xen0n.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loongarch@lists.linux.dev \
    --cc=tangyouling@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).