[Bug target/81863] [7 regression] -mword-relocations is unreliable

[ramana at gcc dot gnu.org]

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 .