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

[Youling Tang <tangyouling@loongson.cn>]

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:
>>>>
>>>> https://github.com/tangyouling/linux/commit/6525b8da
>>>> https://github.com/tangyouling/linux/commit/b6ac0827
>>>>
>>>> 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:
>>>
>>> https://lore.kernel.org/all/20211009171259.2515351-2-alexandre.ghiti@canonical.com/
>>>
>>>
>>>
>>> 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
>>
>> [1] https://github.com/tangyouling/loongarch-next/commits/loongarch-next
>
> 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
> represent.
>
> 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.
>
> [1]
> https://github.com/torvalds/linux/commit/3bbd3db86470c701091fb1d67f1fab6621debf50
>


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
operation.

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


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=be2881824ae

Thanks,
Youling