https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #48 from Ard Biesheuvel <ardb at kernel dot org> --- (In reply to Alexander Monakov from comment #47) > (In reply to Ard Biesheuvel from comment #43) > > 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 :-) > > So unless I botched my grep, there's only a handful of files that employ > RIP_REL_REF, all for position-independent addressing at early startup as you > explain. Considering the macro is effectively used for writing PIE code by > hand, why not compile those files with -fpie in the first place? > > (not -fpic, which would emit GOT-indirect references to global variables > with default, not hidden, visibility) Yes, that is exactly the intent. I already implemented this for arm64 in Linux (see under arch/arm64/kernel/pi) - this subdirectory holds a subset of objects that are compiled with different flags, and linked into the kernel executable along with the other, potentially position dependent code. Note that this code is not necessarily used *only* very early - it might be called from different places at runtime too, so we don't want to be forced to disable the stack protector, ... which brings us to the reason I changed this in the first place: using -fpic or -fpic for those objects would result in GOT based loads of the address of mcount() / __fentry__(), and this is what I wanted to avoid.
