https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
--- Comment #15 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> --- (In reply to ard.biesheuvel from comment #13) > The kernel does not currently use -mword-relocations. We are looking into it > as an alternative to -fpic when building the kernel image as a PIE > executable so we can self-relocate at boot time. This allows for > randomization of the load offset (KASLR) which is an often requested > security feature. > > The problem with -fpic (and even -fpie) is that the compiler infers from its > presence that you are building a shared library which requires preemptible > external symbols and should not contain any text relocations. None of these > concerns apply to the kernel, and the current workaround is to -include a .h > file that sets the visibility 'hidden' pragma, which is a bit tedious. I'm guessing you are aware of -fvisibility=hidden ? > Since we are only interested in absolute references that are runtime > relocatable, -mword-relocations seems like the right choice, but it is > broken currently on v7 (due to this bug) -mword-relocations is probably what you will need for v6t2 and onwards, yes and it's a feature that came in really for symbian / uClinux and thus doesn't get that widely tested. I thought it was also used in kernel modules but my memory is foggy. Yeah ok - I can see where it's going and the same logic can be used everywhere. > > Ideally, we'd have some logic that takes -ffreestanding into account when > deciding how to deal with -fpie/-fpic Uggh hmmm. Alternatively a -mlinux-kernel / -fpie / -fpic ? > > Also, when generating position independent code for v7 or later, we should > probably attempt to use place relative movw/movt pairs rather than relative > literals to emit PC relative references. IIRC we struggle with the relocations .
