Messages in this thread | | | Subject | Re: [PATCH 1/3] LoongArch: tools: Add relocs tool support | From | Youling Tang <> | Date | Fri, 23 Sep 2022 17:56:51 +0800 |
| |
Hi, Ruoyao
On 09/22/2022 07:19 PM, Xi Ruoyao wrote: > On Thu, 2022-09-08 at 16:01 +0800, Youling Tang wrote: >> 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 :(? > > Hi Youling, > > I've pulled your code and make some adjustments for it: > > https://github.com/xry111/linux/commits/xry111/la-dev/pie > > One adjustment is for FDT removal, another uses a static-PIE style > LDFLAGS as the kernel is more "similar" to a static PIE than a shared > library. In userspace, a static PIE is linked with [1]: > > -static -pie --no-dynamic-linker -z text > > [1]: https://gcc.gnu.org/r13-2728 > > But we have to use "-z notext" for vmlinux. I'm not an expert on kernel > hacking, and I guess it's because the kernel doesn't really care the RWX > permission of itself (I heard this during some discussion about a W/X > page warning added in Binutils-2.39 which is triggered for vmlinux). > > With "-static -pie --no-dynamic-linker -z notext" (and GCC trunk & > Binutils trunk), .plt and .got.plt are gone. > > .got is still there but it only contains one entry (8 bytes). AFAIK > this entry (`_GLOBAL_OFFSET_TABLE_[0]`) is set to the link-time address > of _DYNAMIC for a userspace static PIE [2], but vmlinux does not need it > at all. We can tell the linker to discard it IIUC.
Yes, only .got contains one entry (8 bytes) after using LDFLAGS_vmlinux as above, thanks for your help.
Youling.
> > [2]: > https://maskray.me/blog/2021-08-29-all-about-global-offset-table#global_offset_table_0 > > I've boot the kernel successfully and it seems KASLR is in-effect: > > $ sudo cat /proc/kallsyms | grep ' _printk$' > 90000000023b28f4 T _printk > $ grep ' _printk$' /boot/System.map-6.0.0-rc6-pie+ > 90000000009828f4 T _printk >
| |