loongarch.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Youling Tang <tangyouling@loongson.cn>
To: Jinyang He <hejinyang@loongson.cn>
Cc: Xi Ruoyao <xry111@xry111.site>,
	Huacai Chen <chenhuacai@kernel.org>,
	loongarch@lists.linux.dev, LKML <linux-kernel@vger.kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Lulu Cheng <chenglulu@loongson.cn>
Subject: Re: [PATCH v4 0/4] LoongArch: Support new relocation types
Date: Mon, 1 Aug 2022 19:28:43 +0800	[thread overview]
Message-ID: <ba5e99de-0719-af88-4d94-8860787a4251@loongson.cn> (raw)
In-Reply-To: <7b1f9813-85fc-acfd-8e24-7e01469ded3a@loongson.cn>

Hi, Jinyang

On 08/01/2022 06:08 PM, Jinyang He wrote:
> On 08/01/2022 05:55 PM, Xi Ruoyao wrote:
>
>> On Mon, 2022-08-01 at 10:34 +0800, Huacai Chen wrote:
>>> Hi, all,
>>>
>>> On Mon, Aug 1, 2022 at 10:16 AM Youling Tang <tangyouling@loongson.cn>
>>> wrote:
>>>> Hi, Ruoyao
>>>>
>>>> On 07/30/2022 10:52 AM, Xi Ruoyao wrote:
>>>>> On Sat, 2022-07-30 at 10:24 +0800, Xi Ruoyao wrote:
>>>>>> On Sat, 2022-07-30 at 01:55 +0800, Xi Ruoyao wrote:
>>>>>>> On Fri, 2022-07-29 at 20:19 +0800, Youling Tang wrote:
>>>>>>>
>>>>>>>> On 07/29/2022 07:45 PM, Xi Ruoyao wrote:
>>>>>>>>> Hmm... The problem is the "addresses" of per-cpu symbols
>>>>>>>>> are
>>>>>>>>> faked: they
>>>>>>>>> are actually offsets from $r21.  So we can't just load
>>>>>>>>> such an
>>>>>>>>> offset
>>>>>>>>> with PCALA addressing.
>>>>>>>>>
>>>>>>>>> It looks like we'll need to introduce an attribute for GCC
>>>>>>>>> to
>>>>>>>>> make
>>>>>>>>> an
>>>>>>>>> variable "must be addressed via GOT", and add the
>>>>>>>>> attribute into
>>>>>>>>> PER_CPU_ATTRIBUTES.
>>>>>>>> Yes, we need a GCC attribute to specify the per-cpu
>>>>>>>> variable.
>>>>>>> GCC patch adding "addr_global" attribute for LoongArch:
>>>>>>> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599064.html
>>>>>>>
>>>>>>> An experiment to use it:
>>>>>>> https://github.com/xry111/linux/commit/c1d5d70
>>>>>> Correction: https://github.com/xry111/linux/commit/c1d5d708
>>>>>>
>>>>>> It seems 7-bit SHA is not enough for kernel repo.
>>>>> If addr_global is rejected or not implemented (for example,
>>>>> building the
>>>>> kernel with GCC 12), *I expect* the following hack to work (I've
>>>>> not
>>>>> tested it because I'm AFK now).  Using visibility in kernel seems
>>>>> strange, but I think it may make some sense because the modules
>>>>> are some
>>>>> sort of similar to an ELF shared object being dlopen()'ed, and our
>>>>> way
>>>>> to inject per-CPU symbols is analog to ELF interposition.
>>>>>
>>>>> arch/loongarch/include/asm/percpu.h:
>>>>>
>>>>>     #if !__has_attribute(__addr_global__) && defined(MODULE)
>>>>>     /* Magically remove "static" for per-CPU variables.  */
>>>>>     # define ARCH_NEEDS_WEAK_PER_CPU
>>>>>     /* Force GOT-relocation for per-CPU variables.  */
>>>>>     # define PER_CPU_ATTRIBUTES
>>>>> __attribute__((__visibility__("default")))
>>>>>     #endif
>>>>>
>>>>> arch/loongarch/Makefile:
>>>>>
>>>>>     # Hack for per-CPU variables, see PER_CPU_ATTRIBUTES in
>>>>>     # include/asm/percpu.h
>>>>>     if (call gcc-does-not-support-addr-global)
>>>>>       KBUILD_CFLAGS_MODULE += -fPIC -fvisibility=hidden
>>>>>     endif
>>>>>
>>>> Using the old toolchain (GCC 12) can successfully load the
>>>> nf_tables.ko
>>>> module after applying the above patch.
>>> I don't like such a hack..., can we consider using old relocation
>>> types when building by old toolchains?
>>
>> I don't like the hack too.  I only developed it as an intellectual game.
>>
>> We need to consider multiple combinations:
>>
>> (1) Old GCC + old Binutils.  We need -mla-local-with-abs for
>> KBUILD_CFLAGS_MODULE.
>>
>> (2) Old GCC + new Binutils.  We need -mla-local-with-abs for
>> KBUILD_CFLAGS_MODULE, *and* adding the support for
>> R_LARCH_ABS{_HI20,_LO12,64_LO20,64_HI12} in the kernel module loader.
>>
>> (3) New GCC + old Binutils.  As new GCC should support our new attribute
>> (I now intend to send V2 patch to gcc-patches using "movable" as the
>> attribute name), no special action is needed.
>>
>> Basically, we need:
>>
>> (1) Handle R_LARCH_ABS{_HI20,_LO12,64_LO20,64_HI12} in the kernel module
>> loader.
>> (2) Add -Wa,-mla-local-with-abs into KBUILD_CFLAGS_MODULE if GCC version
>> is <= 12.
>
> Actually, I really hope kernel image is in the XKVRANGE, rather
> than being in XKPRANGE. So that we can limit kernel and modules
> be in 4GB range. I think it will make all work normally. :-(
>

Assuming that the kernel and modules are limited to 4G, the external
symbols will be accessed through pcrel32, which means that there is no
need to pass the GOT table entry, and there is no need for got support,
so there will be no percpu problem, and it will make all work normally?

Youling.


  parent reply	other threads:[~2022-08-01 11:28 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29  8:38 [PATCH v4 0/4] LoongArch: Support new relocation types Xi Ruoyao
2022-07-29  8:39 ` [PATCH v4 1/4] LoongArch: Add section of GOT for kernel module Xi Ruoyao
2022-07-29  8:40 ` [PATCH v4 2/4] LoongArch: Support R_LARCH_SOP_PUSH_GPREL relocation type in " Xi Ruoyao
2022-07-29  8:41 ` [PATCH v4 3/4] LoongArch: Remove -fplt and -Wa,-mla-* from CFLAGS Xi Ruoyao
2022-07-29  8:42 ` [PATCH v4 4/4] LoongArch: Support modules with new relocation types Xi Ruoyao
2022-08-01  9:45   ` Youling Tang
2022-08-09 11:31   ` Youling Tang
2022-07-29  9:47 ` [PATCH v4 0/4] LoongArch: Support " WANG Xuerui
2022-07-29  9:49 ` Youling Tang
2022-07-29 10:18   ` Xi Ruoyao
2022-07-29 10:36     ` Xi Ruoyao
2022-07-29 11:45       ` Xi Ruoyao
2022-07-29 12:19         ` Youling Tang
2022-07-29 17:55           ` Xi Ruoyao
2022-07-30  2:24             ` Xi Ruoyao
2022-07-30  2:52               ` Xi Ruoyao
2022-07-30  6:14                 ` Huacai Chen
     [not found]                   ` <674cb3e9-d820-016b-a210-afd37ed6e25e@loongson.cn>
2022-07-30  9:51                     ` Xi Ruoyao
2022-07-30 10:38                       ` Huacai Chen
2022-07-31  3:07                         ` Xi Ruoyao
2022-08-01  2:16                 ` Youling Tang
2022-08-01  2:34                   ` Huacai Chen
2022-08-01  4:31                     ` Youling Tang
2022-08-01  9:55                     ` Xi Ruoyao
2022-08-01 10:08                       ` Jinyang He
2022-08-01 10:44                         ` WANG Xuerui
2022-08-01 11:28                         ` Youling Tang [this message]
2022-08-01 11:39                           ` Xi Ruoyao
2022-08-01 12:09                             ` Huacai Chen
2022-08-01 12:13                             ` Youling Tang
     [not found]                               ` <98efbf76-fbf3-f90b-82d4-bd2874088d05@loongson.cn>
2022-08-02  7:15                                 ` Xi Ruoyao
2022-08-27 13:20                                   ` Huacai Chen
2022-08-01 10:41                       ` Huacai Chen

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=ba5e99de-0719-af88-4d94-8860787a4251@loongson.cn \
    --to=tangyouling@loongson.cn \
    --cc=chenglulu@loongson.cn \
    --cc=chenhuacai@kernel.org \
    --cc=hejinyang@loongson.cn \
    --cc=kernel@xen0n.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loongarch@lists.linux.dev \
    --cc=xry111@xry111.site \
    /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).