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 the following combinations:
- GCC 12 and Binutils 2.39
- GCC 12 and Binutils trunk
- GCC trunk and Binutils trunk
and running the builds with 35 in-tree modules loaded, and loading one
module with 20 GOT loads and a per-CPU variable (loaded addresses
verified by comparing with /proc/kallsyms).
This superseds "LoongArch: Support new relocation types" series. I
don't make it a "v5" because too much things have changed so it's better
to treat this as a new series.
Xi Ruoyao (8):
LoongArch: Add CONFIG_CC_HAS_EXPLICIT_RELOCS
LoongArch: Only use -Wa,-mla-* options for
!CONFIG_CC_HAS_EXPLICIT_RELOCS
LoongArch: Define ELF relocation types added in v2.00 ABI
LoongArch: Support R_LARCH_B26 in modules
LoongArch: Support R_LARCH_ABS* in modules
LoongArch: Use model("extreme") attribute for per-CPU variables in
module if CONFIG_CC_HAS_EXPLICIT_RELOCS
LoongArch: Support R_LARCH_PCALA* in modules
LoongArch: Support R_LARCH_GOT_PC* in modules
arch/loongarch/Kconfig | 3 +
arch/loongarch/Makefile | 15 ++-
arch/loongarch/include/asm/elf.h | 37 +++++++
arch/loongarch/include/asm/module.h | 23 ++++
arch/loongarch/include/asm/module.lds.h | 1 +
arch/loongarch/include/asm/percpu.h | 13 +++
arch/loongarch/kernel/head.S | 10 +-
arch/loongarch/kernel/module-sections.c | 56 +++++++++-
arch/loongarch/kernel/module.c | 138 +++++++++++++++++++++++-
9 files changed, 285 insertions(+), 11 deletions(-)
--
2.37.0
Hi, Ruoyao,
On Sun, Aug 28, 2022 at 1:55 AM Xi Ruoyao <[email protected]> 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 the following combinations:
>
> - GCC 12 and Binutils 2.39
> - GCC 12 and Binutils trunk
> - GCC trunk and Binutils trunk
>
> and running the builds with 35 in-tree modules loaded, and loading one
> module with 20 GOT loads and a per-CPU variable (loaded addresses
> verified by comparing with /proc/kallsyms).
>
> This superseds "LoongArch: Support new relocation types" series. I
> don't make it a "v5" because too much things have changed so it's better
> to treat this as a new series.
1, You can still call it v5, even if it has changed a lot;
2, In my opinion, patch 4,5,7,8 can be combined, but I don't insist if
you have a good reason to separate.
3, If possible, I still prefer to remove old relocation types support,
in order to make life easier, especially for objtool that is queued
for upstream.
Huacai
>
> Xi Ruoyao (8):
> LoongArch: Add CONFIG_CC_HAS_EXPLICIT_RELOCS
> LoongArch: Only use -Wa,-mla-* options for
> !CONFIG_CC_HAS_EXPLICIT_RELOCS
> LoongArch: Define ELF relocation types added in v2.00 ABI
> LoongArch: Support R_LARCH_B26 in modules
> LoongArch: Support R_LARCH_ABS* in modules
> LoongArch: Use model("extreme") attribute for per-CPU variables in
> module if CONFIG_CC_HAS_EXPLICIT_RELOCS
> LoongArch: Support R_LARCH_PCALA* in modules
> LoongArch: Support R_LARCH_GOT_PC* in modules
>
> arch/loongarch/Kconfig | 3 +
> arch/loongarch/Makefile | 15 ++-
> arch/loongarch/include/asm/elf.h | 37 +++++++
> arch/loongarch/include/asm/module.h | 23 ++++
> arch/loongarch/include/asm/module.lds.h | 1 +
> arch/loongarch/include/asm/percpu.h | 13 +++
> arch/loongarch/kernel/head.S | 10 +-
> arch/loongarch/kernel/module-sections.c | 56 +++++++++-
> arch/loongarch/kernel/module.c | 138 +++++++++++++++++++++++-
> 9 files changed, 285 insertions(+), 11 deletions(-)
>
> --
> 2.37.0
>
On Sun, 2022-08-28 at 22:15 +0800, Huacai Chen wrote:
> 1, You can still call it v5, even if it has changed a lot;
Ok, so should I call the next version v2 or v6?
Sorry for introducing such a mess :(.
> 2, In my opinion, patch 4,5,7,8 can be combined, but I don't insist if
> you have a good reason to separate.
If we'll drop support for old GCC/Binutils, we can drop patch 5 (it's
only needed for the combination of old GCC and new Binutils). Then
squash 4 and 7. 8 should still be standalone IMO.
> 3, If possible, I still prefer to remove old relocation types support,
> in order to make life easier, especially for objtool that is queued
> for upstream.
How about this? I'm not sure if it's proper to invoke "error" in
Makefile.
ifneq ($(shell $(CC) $(srctree)/arch/loongarch/scripts/toolchain-check.c &> /dev/null -o /dev/null && echo "ok"), ok)
ifdef CONFIG_MODULES
$(error "toolchain is too old for LoongArch modular kernel")
endif
endif
toolchain-check.c:
#if !__has_attribute(model)
#error no model attribute
#endif
int main()
{
__asm__("x:pcalau12i $t0,%pc_hi20(x)");
}
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
Hi, Ruoyao,
On Mon, Aug 29, 2022 at 12:17 AM Xi Ruoyao <[email protected]> wrote:
>
> On Sun, 2022-08-28 at 22:15 +0800, Huacai Chen wrote:
> > 1, You can still call it v5, even if it has changed a lot;
>
> Ok, so should I call the next version v2 or v6?
V6 is reasonable to me.
>
> Sorry for introducing such a mess :(.
>
> > 2, In my opinion, patch 4,5,7,8 can be combined, but I don't insist if
> > you have a good reason to separate.
>
> If we'll drop support for old GCC/Binutils, we can drop patch 5 (it's
> only needed for the combination of old GCC and new Binutils). Then
> squash 4 and 7. 8 should still be standalone IMO.
Whether we can drop old toolchains depends on Arnd. :)
But even if we should support old toolchains, I think we only need to
consider new binutils + new gcc and old binutils + old gcc, I don't
think new binutils + old gcc and old binutils + new gcc can exist in
the real world.
>
> > 3, If possible, I still prefer to remove old relocation types support,
> > in order to make life easier, especially for objtool that is queued
> > for upstream.
>
> How about this? I'm not sure if it's proper to invoke "error" in
> Makefile.
>
> ifneq ($(shell $(CC) $(srctree)/arch/loongarch/scripts/toolchain-check.c &> /dev/null -o /dev/null && echo "ok"), ok)
> ifdef CONFIG_MODULES
> $(error "toolchain is too old for LoongArch modular kernel")
> endif
> endif
>
> toolchain-check.c:
>
> #if !__has_attribute(model)
> #error no model attribute
> #endif
>
> int main()
> {
> __asm__("x:pcalau12i $t0,%pc_hi20(x)");
> }
Compared to toolchain-check.c, I prefer to change Kconfig, so please
keep the old way. But since new binutils + old gcc and old binutils +
new gcc can hardly exist, can we only check the gcc features
(explicit-relocs and has_attribute)?
Huacai
> --
> Xi Ruoyao <[email protected]>
> School of Aerospace Science and Technology, Xidian University
On Mon, 2022-08-29 at 12:33 +0800, Huacai Chen wrote:
> > If we'll drop support for old GCC/Binutils, we can drop patch 5 (it's
> > only needed for the combination of old GCC and new Binutils). Then
> > squash 4 and 7. 8 should still be standalone IMO.
> Whether we can drop old toolchains depends on Arnd. :)
I'd like to prepare V6 after we can make a final decision.
> But even if we should support old toolchains, I think we only need to
> consider new binutils + new gcc and old binutils + old gcc, I don't
> think new binutils + old gcc and old binutils + new gcc can exist in
> the real world.
Generally, how do we report an unsupported configuration in kernel
building system? With a $(error, "message") in the Makefile, or in some
header with a #error? I don't want to leave an unsupported
configuration silently generating modules which can't be loaded by the
kernel.
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
Hi, Ruoyao,
On Mon, Aug 29, 2022 at 1:04 PM Xi Ruoyao <[email protected]> wrote:
>
> On Mon, 2022-08-29 at 12:33 +0800, Huacai Chen wrote:
> > > If we'll drop support for old GCC/Binutils, we can drop patch 5 (it's
> > > only needed for the combination of old GCC and new Binutils). Then
> > > squash 4 and 7. 8 should still be standalone IMO.
>
> > Whether we can drop old toolchains depends on Arnd. :)
>
> I'd like to prepare V6 after we can make a final decision.
I think we can assume that we should support old toolchains until Arnd
responds, but again, we can only consider new/new and old/old.
>
> > But even if we should support old toolchains, I think we only need to
> > consider new binutils + new gcc and old binutils + old gcc, I don't
> > think new binutils + old gcc and old binutils + new gcc can exist in
> > the real world.
>
> Generally, how do we report an unsupported configuration in kernel
> building system? With a $(error, "message") in the Makefile, or in some
> header with a #error? I don't want to leave an unsupported
> configuration silently generating modules which can't be loaded by the
> kernel.
$(error, "message") in the Makefile is fine to me, you can "grep
error arch -rwI | grep Makefile".
Huacai
>
> --
> Xi Ruoyao <[email protected]>
> School of Aerospace Science and Technology, Xidian University
>