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

[Youling Tang]

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@xxxxxxxxxxxxx/
> > >
> > >
> > >
> > > 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