arch/loongarch/Makefile | 4 -- arch/loongarch/include/asm/elf.h | 37 ++++++++++ arch/loongarch/include/asm/module.h | 23 ++++++ arch/loongarch/include/asm/module.lds.h | 1 + arch/loongarch/kernel/head.S | 10 +-- arch/loongarch/kernel/module-sections.c | 51 +++++++++++-- arch/loongarch/kernel/module.c | 96 +++++++++++++++++++++++++ 7 files changed, 209 insertions(+), 13 deletions(-)
The version 2.00 of LoongArch ELF ABI specification introduced new
relocation types, and the development tree of Binutils and GCC has
started to use them. If the kernel is built with the latest snapshot of
Binutils or GCC, it will fail to load the modules because of unrecognized
relocation types in modules.
Add support for GOT and new relocation types for the module loader, so
the kernel (with modules) can be built with the "normal" code model and
function properly.
This series does not break the compatibility with old toolchain using
stack-based relocation types, so with the patches applied the kernel can
be be built with both old and new toolchains.
Tested by building the kernel with both Binutils & GCC master branch and
my system Binutils & GCC (without new relocation type support), running
both the builds with 35 in-tree modules loaded, and loading one module
with 20 GOT loads (loaded addresses verified by comparing with
/proc/kallsyms).
Changes from v3 to v4:
- No code change. Reword the commit message of the 3rd patch again
based on suggestion from Huacai.
Changes from v2 to v3:
- Use `union loongarch_instruction` instead of explicit bit shifts
applying the relocation. Suggested by Youling.
- For R_LARCH_B26, move the alignment check before the range check to be
consistent with stack pop relocations. Suggested by Youling.
- Reword the commit message of the 3rd patch. Suggested by Huacai.
Changes from v1 to v2:
- Fix a stupid programming error (confusion between the number of PLT
entries and the number of GOT entries). (Bug spotted by Youling).
- Synthesize the _GLOBAL_OFFSET_TABLE_ symbol with module.lds, instead
of faking it at runtime. The 3rd patch from V1 is now merged into
the 1st patch because it would be a one-line change. (Suggested by
Jinyang).
- Keep reloc_rela_handlers[] ordered by the relocation type ID.
(Suggested by Youling).
- Remove -fplt along with -Wa,-mla-* options because it's the default.
(Suggested by Youling).
Xi Ruoyao (4):
LoongArch: Add section of GOT for kernel module
LoongArch: Support R_LARCH_SOP_PUSH_GPREL relocation type in kernel
module
LoongArch: Remove -fplt and -Wa,-mla-* from CFLAGS
LoongArch: Support modules with new relocation types
arch/loongarch/Makefile | 4 --
arch/loongarch/include/asm/elf.h | 37 ++++++++++
arch/loongarch/include/asm/module.h | 23 ++++++
arch/loongarch/include/asm/module.lds.h | 1 +
arch/loongarch/kernel/head.S | 10 +--
arch/loongarch/kernel/module-sections.c | 51 +++++++++++--
arch/loongarch/kernel/module.c | 96 +++++++++++++++++++++++++
7 files changed, 209 insertions(+), 13 deletions(-)
--
2.37.0
Hi, Ruoyao Tested this series of patches v3 on a CLFS 5.5 system, using the new cross toolchain, $ dmesg | head [ 0.000000] Linux version 5.19.0-rc7new-toolchain+ (loongson@linux) (loongarch64-unknown-linux-gnu-gcc (GCC) 13.0.0 20220726 (experimental) [master revision cf7eac5805e:1e0611b64d8:3fb68f2e666d9de7e0326af9f43b12c9e98f19a6], GNU ld (GNU Binutils) 2.39.50.20220726) #1 SMP PREEMPT Fri Jul 29 05:24:15 EDT 2022 Relocation error when manually loading nf_tables.ko module, $ sudo modprobe nf_tables odprobe: ERROR: could not insert 'nf_tables': Exec format error $ dmesg [ 61.506737] kmod: module nf_tables: PCALA offset = 0x90007ffffed8c000 does not fit in 32-bit signed and is unsupported by kernel! dangerous apply_r_larch_pcala_hi20 (71) relocation Do you have the same problem over there? Thanks, Youling On 07/29/2022 04:38 PM, Xi Ruoyao wrote: > The version 2.00 of LoongArch ELF ABI specification introduced new > relocation types, and the development tree of Binutils and GCC has > started to use them. If the kernel is built with the latest snapshot of > Binutils or GCC, it will fail to load the modules because of unrecognized > relocation types in modules. > > Add support for GOT and new relocation types for the module loader, so > the kernel (with modules) can be built with the "normal" code model and > function properly. > > This series does not break the compatibility with old toolchain using > stack-based relocation types, so with the patches applied the kernel can > be be built with both old and new toolchains. > > Tested by building the kernel with both Binutils & GCC master branch and > my system Binutils & GCC (without new relocation type support), running > both the builds with 35 in-tree modules loaded, and loading one module > with 20 GOT loads (loaded addresses verified by comparing with > /proc/kallsyms). > > Changes from v3 to v4: > > - No code change. Reword the commit message of the 3rd patch again > based on suggestion from Huacai. > > Changes from v2 to v3: > > - Use `union loongarch_instruction` instead of explicit bit shifts > applying the relocation. Suggested by Youling. > - For R_LARCH_B26, move the alignment check before the range check to be > consistent with stack pop relocations. Suggested by Youling. > - Reword the commit message of the 3rd patch. Suggested by Huacai. > > Changes from v1 to v2: > > - Fix a stupid programming error (confusion between the number of PLT > entries and the number of GOT entries). (Bug spotted by Youling). > - Synthesize the _GLOBAL_OFFSET_TABLE_ symbol with module.lds, instead > of faking it at runtime. The 3rd patch from V1 is now merged into > the 1st patch because it would be a one-line change. (Suggested by > Jinyang). > - Keep reloc_rela_handlers[] ordered by the relocation type ID. > (Suggested by Youling). > - Remove -fplt along with -Wa,-mla-* options because it's the default. > (Suggested by Youling). > > Xi Ruoyao (4): > LoongArch: Add section of GOT for kernel module > LoongArch: Support R_LARCH_SOP_PUSH_GPREL relocation type in kernel > module > LoongArch: Remove -fplt and -Wa,-mla-* from CFLAGS > LoongArch: Support modules with new relocation types > > arch/loongarch/Makefile | 4 -- > arch/loongarch/include/asm/elf.h | 37 ++++++++++ > arch/loongarch/include/asm/module.h | 23 ++++++ > arch/loongarch/include/asm/module.lds.h | 1 + > arch/loongarch/kernel/head.S | 10 +-- > arch/loongarch/kernel/module-sections.c | 51 +++++++++++-- > arch/loongarch/kernel/module.c | 96 +++++++++++++++++++++++++ > 7 files changed, 209 insertions(+), 13 deletions(-) >
On Fri, 2022-07-29 at 17:49 +0800, Youling Tang wrote: > Hi, Ruoyao > > Tested this series of patches v3 on a CLFS 5.5 system, using the new > cross toolchain, > $ dmesg | head > [ 0.000000] Linux version 5.19.0-rc7new-toolchain+ (loongson@linux) > (loongarch64-unknown-linux-gnu-gcc (GCC) 13.0.0 20220726 (experimental) > [master revision > cf7eac5805e:1e0611b64d8:3fb68f2e666d9de7e0326af9f43b12c9e98f19a6], GNU > ld (GNU Binutils) 2.39.50.20220726) #1 SMP PREEMPT Fri Jul 29 05:24:15 > EDT 2022 > > Relocation error when manually loading nf_tables.ko module, > $ sudo modprobe nf_tables > odprobe: ERROR: could not insert 'nf_tables': Exec format error > > $ dmesg > [ 61.506737] kmod: module nf_tables: PCALA offset = 0x90007ffffed8c000 > does not fit in 32-bit signed and is unsupported by kernel! dangerous > apply_r_larch_pcala_hi20 (71) relocation > > Do you have the same problem over there? I can reproduce it with "modprobe x_tables". Will try to debug...
On Fri, 2022-07-29 at 18:18 +0800, Xi Ruoyao wrote: > On Fri, 2022-07-29 at 17:49 +0800, Youling Tang wrote: > > Hi, Ruoyao > > > > Tested this series of patches v3 on a CLFS 5.5 system, using the new > > cross toolchain, > > $ dmesg | head > > [ 0.000000] Linux version 5.19.0-rc7new-toolchain+ (loongson@linux) > > (loongarch64-unknown-linux-gnu-gcc (GCC) 13.0.0 20220726 (experimental) > > [master revision > > cf7eac5805e:1e0611b64d8:3fb68f2e666d9de7e0326af9f43b12c9e98f19a6], GNU > > ld (GNU Binutils) 2.39.50.20220726) #1 SMP PREEMPT Fri Jul 29 05:24:15 > > EDT 2022 > > > > Relocation error when manually loading nf_tables.ko module, > > $ sudo modprobe nf_tables > > odprobe: ERROR: could not insert 'nf_tables': Exec format error > > > > $ dmesg > > [ 61.506737] kmod: module nf_tables: PCALA offset = 0x90007ffffed8c000 > > does not fit in 32-bit signed and is unsupported by kernel! dangerous > > apply_r_larch_pcala_hi20 (71) relocation > > > > Do you have the same problem over there? > > I can reproduce it with "modprobe x_tables". Will try to debug... The relocation against local percpu variable is broken up. I'll try to fix it. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University
On Fri, 2022-07-29 at 18:36 +0800, Xi Ruoyao wrote: > The relocation against local percpu variable is broken up. I'll try > to fix it. 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. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University
On 07/29/2022 07:45 PM, Xi Ruoyao wrote: > On Fri, 2022-07-29 at 18:36 +0800, Xi Ruoyao wrote: > >> The relocation against local percpu variable is broken up. I'll try >> to fix it. > > 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. Thanks, Youling >
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 This fixes "modprobe x_tables" for me. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University
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. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University
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
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
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.
Thanks,
Youling
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?
Huacai
>
> Thanks,
> Youling
>
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.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
Hi, Ruoyao,
On Mon, Aug 1, 2022 at 5:55 PM Xi Ruoyao <xry111@xry111.site> 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.
There is another simple solution: just refuse to build if the
toolchain is too old.
Huacai
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University
>
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. :-(
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.
On Mon, 2022-08-01 at 19:28 +0800, Youling Tang wrote: > > 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 We'll still need to modify GCC to use PC-rel for accessing an object in another TU (by default, or an option to control), instead of GOT. Or just add support to GOT relocations here. But anyway it will be much easier as we won't need to handle per-CPU variables specially. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University
On 08/01/2022 07:39 PM, Xi Ruoyao wrote: > On Mon, 2022-08-01 at 19:28 +0800, Youling Tang wrote: > >>> 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 > > We'll still need to modify GCC to use PC-rel for accessing an object in > another TU (by default, or an option to control), instead of GOT. Or > just add support to GOT relocations here. But anyway it will be much > easier as we won't need to handle per-CPU variables specially. > OO, old toolchains require extra handlingg no matter how modified. Maybe rejecting old toolchain builds is a good option as Huacai said. Youling.
Hi, Ruoyao, On Mon, Aug 1, 2022 at 7:40 PM Xi Ruoyao <xry111@xry111.site> wrote: > > On Mon, 2022-08-01 at 19:28 +0800, Youling Tang wrote: > > > > 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 > > We'll still need to modify GCC to use PC-rel for accessing an object in > another TU (by default, or an option to control), instead of GOT. Or > just add support to GOT relocations here. But anyway it will be much > easier as we won't need to handle per-CPU variables specially. All tlb-mapped kernel may be supported in future, but no now. Because there are a ton of problems. :) Huacai > -- > Xi Ruoyao <xry111@xry111.site> > School of Aerospace Science and Technology, Xidian University
On 2022/8/1 18:08, Jinyang He wrote: > [snip] > > 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. :-( Just my 2c. I'd prefer any scheme in which memfd_secret is possible. The current design makes it impossible to carve out memory regions from kernel's view, IIUC, which is of course something to improve... -- WANG "xen0n" Xuerui Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
Hi, all
On 08/01/2022 10:34 AM, 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
Using the new toolchain (with the "addr_global" attribute) to build the
kernel can successfully load the nf_tables.ko module after applying the
"c1d5d708" commit.
Thanks,
Youling
>>>>
>>>> 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?
>
> Huacai
>>
>> Thanks,
>> Youling
>>
Hi, Ruoyao,
On Sat, Jul 30, 2022 at 10:53 AM Xi Ruoyao <xry111@xry111.site> 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.
Sadly, I don't know what visibility is, does it have something to do
with __visible in include/linux/compiler_attributes.h?
Huacai
>
> 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
>
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University
>
On 2022/7/29 16:38, Xi Ruoyao wrote: > The version 2.00 of LoongArch ELF ABI specification introduced new > relocation types, and the development tree of Binutils and GCC has > started to use them. If the kernel is built with the latest snapshot of > Binutils or GCC, it will fail to load the modules because of unrecognized > relocation types in modules. > > Add support for GOT and new relocation types for the module loader, so > the kernel (with modules) can be built with the "normal" code model and > function properly. > > This series does not break the compatibility with old toolchain using > stack-based relocation types, so with the patches applied the kernel can > be be built with both old and new toolchains. > > Tested by building the kernel with both Binutils & GCC master branch and > my system Binutils & GCC (without new relocation type support), running > both the builds with 35 in-tree modules loaded, and loading one module > with 20 GOT loads (loaded addresses verified by comparing with > /proc/kallsyms). > > Changes from v3 to v4: > > - No code change. Reword the commit message of the 3rd patch again > based on suggestion from Huacai. > > Changes from v2 to v3: > > - Use `union loongarch_instruction` instead of explicit bit shifts > applying the relocation. Suggested by Youling. > - For R_LARCH_B26, move the alignment check before the range check to be > consistent with stack pop relocations. Suggested by Youling. > - Reword the commit message of the 3rd patch. Suggested by Huacai. > > Changes from v1 to v2: > > - Fix a stupid programming error (confusion between the number of PLT > entries and the number of GOT entries). (Bug spotted by Youling). > - Synthesize the _GLOBAL_OFFSET_TABLE_ symbol with module.lds, instead > of faking it at runtime. The 3rd patch from V1 is now merged into > the 1st patch because it would be a one-line change. (Suggested by > Jinyang). > - Keep reloc_rela_handlers[] ordered by the relocation type ID. > (Suggested by Youling). > - Remove -fplt along with -Wa,-mla-* options because it's the default. > (Suggested by Youling). > > Xi Ruoyao (4): > LoongArch: Add section of GOT for kernel module > LoongArch: Support R_LARCH_SOP_PUSH_GPREL relocation type in kernel > module > LoongArch: Remove -fplt and -Wa,-mla-* from CFLAGS > LoongArch: Support modules with new relocation types > > arch/loongarch/Makefile | 4 -- > arch/loongarch/include/asm/elf.h | 37 ++++++++++ > arch/loongarch/include/asm/module.h | 23 ++++++ > arch/loongarch/include/asm/module.lds.h | 1 + > arch/loongarch/kernel/head.S | 10 +-- > arch/loongarch/kernel/module-sections.c | 51 +++++++++++-- > arch/loongarch/kernel/module.c | 96 +++++++++++++++++++++++++ > 7 files changed, 209 insertions(+), 13 deletions(-) > Thanks very much for the timely adaptation. I'm rebuilding my Gentoo toolchain from upstream HEAD, will test this weekend. -- WANG "xen0n" Xuerui Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
© 2016 - 2026 Red Hat, Inc.