On 09/07/2022 06:19 PM, Youling Tang wrote:
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
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 , 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 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  and only