Re: [PATCH 1/3] LoongArch: tools: Add relocs tool support

From: Youling Tang
Date: Thu Sep 08 2022 - 04:02:17 EST

On 09/08/2022 10:44 AM, Youling Tang wrote:
Hi, Ruoyao

On 09/07/2022 06:19 PM, Youling Tang wrote:
Hi, Ruoyao

On 09/06/2022 01:17 PM, Xi Ruoyao wrote:
On Tue, 2022-09-06 at 10:16 +0800, Youling Tang wrote:

Switch to relative exception tables:

Will switch to the relative exception tables after applying the above
two patches. So there is no need to relocate the exception table
(remove relocate_exception_table).

Now we can remove the relocation of la.abs , got and ex_table, but
still need to relocate LARCH_64. Is there anything else that needs to
be modified to eliminate this relocation?

You may see the RISC-V patch as a reference:

Basically, make the linker to generate R_*_RELATIVE instead of R_*_64
for pointers. And, perform R_*_RELATIVE relocation loading the kernel.

Something problematic IMO: RISC-V uses "-shared" to trick the linker to
generate R_*_RELATIVE but I consider it ugly (if the kernel is a shared
library, my grandma will be a wagon!) I prefer "-pie -static", but our
Glibc does not have static-pie support for now. It won't really affect
the kernel (we are -nostdlib), but we cannot learn how to handle
R_*_RELATIVE in static pie from Glibc then.

After applying all the patches in the link [1], the implementation of
the relocs tool can now be removed :).

commit: 244fb0971a ... ad45233ef6


The previous LDFLAGS_vmlinux has not changed,
LDFLAGS_vmlinux += -G0 -static -n -nostdlib

When enabling CONFIG_RELOCATABLE to generate the PIE kernel, link
vmliunx with different flags:

1)LDFLAGS_vmlinux += -shared -Bsymbolic -z notext -z norelro
This way is similar to arm64.

The following warnings appear when linking when using the old toolchain
(no warnings for the new toolchain):

kernel/kallsyms.o(.text+0x4): warning: R_LARCH_SOP_PUSH_PCREL against
[undefweak] `kallsyms_offsets':
Undefweak need to be resolved dynamically, but PLT stub doesn't

2)LDFLAGS_vmlinux += -pie
No warnings appear, it looks fine together.

I looked at some commits for arm64, at first arm64 used -pie -shared
(direct link fails in LoongArch), Removed -pie after link [1] and only
used -shared.


After adding KBUILD_CFLAGS_KERNEL += -mdirect-extern-access, the kernel
will not generate .got, .plt and .got.plt sections (in the new
toolchain), we should unexpectedly detect that the kernel has these
sections, maybe add similar patch [1] to detect, x86_64 has the same

But when adding LDFLAGS_vmlinux += -pie (or -shared), there will be
.got, .plt and .got.plt sections generated, I don't know how the
toolchain handles it :(?

$ loongarch64-unknown-linux-gnu-readelf -S vmlinux
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 4] .plt PROGBITS 90000000010215e0 00e315e0
0000000000000040 0000000000000010 AX 0 0 16
[ 5] .got.plt PROGBITS 9000000001021620 00e31620
0000000000000020 0000000000000008 WA 0 0 8
[ 6] .got PROGBITS 9000000001021640 00e31640
0000000000000008 0000000000000008 WA 0 0 8