https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #43 from Ard Biesheuvel <ardb at kernel dot org> --- (In reply to Alexander Monakov from comment #42) > > In Linux, we don't even bother with PIC codegen, even though we link with > > -pie. > > My git-grep for that is coming up empty, where should I look? > arch/arm64/Makefile specifies '-shared' for the linker flags, but does not pass -fpic of -fpie to the compiler. We used to pass '-pie -shared' but that was changed a while ago to accommodate lld. > > > ... on x86_64, where PIC and non-PIC codegen are radically different, and > > non-PIC codegen for the kernel is different again from non-PIC codegen for > > user space. > > Do you mean that on arm64 PIC vs. non-PIC differences are less radical? Or > there's no interest in building [parts of] the kernel with -fPIE for arm64? > The goal is to build a PIE (or -shared) executable, so that we get the dynamic relocations needed to randomize the placement of the kernel in the virtual address space at boot. On arm64, that doesn't currently require -fpic of -fpie, and adding those options results in worse code due to all the GOT indirections. > > No there is not. I was referring to arm64 before, where non-PIC codegen is > > actually better for us than PIC codegen, because it omits all the GOT stuff > > and other things that are only relevant to shared libraries in user space > > (symbol preemption, reducing the CoW footprint of writable segments, etc) > > I still find myself confused, because non-PIC is going to be more efficient > everywhere for the same reasons, not just on arm64. Non-PIC might be more efficient, but there are cases where we cannot use it. The early startup code on x86 runs from a different virtual mapping than it was linked at, and this has been causing lots of issues. Grep for RIP_REL_REF() in the Linux source tree and weep :-)
