https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #44 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> --- (In reply to Christophe Lyon from comment #39) > We have backported r227748, 229160 and 229161 to our linaro-gcc-5 branch, > and we got a bug report from the kernel team. Sorry about the breakage. > > Indeed, when the kernel is configured with CONFIG_ARM64_ERRATUM_843419, the > support for relocations R_AARCH64_ADR_PREL_PG_HI21 and > R_AARCH64_ADR_PREL_PG_HI21_NC is removed from the kernel to avoid loading > objects with possibly offending sequences. In this case the kernel is built > with > -mcmodel=large. > > With these backports, these relocations are generated again by default. The reason for the code generation to be in this form , is to store literal pools in rodata and not have any data in the code segment at all. Now when these need to be addressed that far away, addressing them with adrp / load is reasonable as you are thinking of a text + rodata segment to be > 4GB before this fails. In an ideal world this would be implemented by the 4 insn mov / movk sequence to construct the literal address, however those relocations are not likely to be supported by the kernel loader (or rather I haven't checked). > > Adding -mpc-relative-literal-loads to the kernel Makefile in > arch/arm64/Makefile does fix the build, but since this option is not > supported by GCC if it does not contain these backports (and the compiler > aborts with an error), it's not obvious how to modify the Makefile to decide > when to use this option. (In reply to Christophe Lyon from comment #43) > Indeed, that seems safer. > However, reading http://www.spinics.net/lists/arm-kernel/msg445346.html > there is a comment saying: > ---------------------- > Note that the kernel itself must be linked with a version of ld > which fixes potentially affected ADRP instructions through the > use of veneers > ----------------------- > > But I don't know how this is enforced. With kernel modules, there's no way the linker fix can be used as kernel modules are simply put just object files. When I did the work, I had forgotten about the erratum and the repercussions on kernel modules. Thus -mpc-relative-literal-loads is quite a reasonable workaround to the problem. > > Or... change GCC's -mfix-cortex-a53-843419 to change the default for > -mpc-relative-literal-loads and add -mfix-cortex-a53-843419 to the kernel > Makefile. That's probably not that bad an idea as a short term workaround for GCC 6.
