On 7 March 2016 at 05:49, Ramana Radhakrishnan <ramana....@googlemail.com> wrote: > On Tue, Jan 26, 2016 at 2:42 PM, Christophe Lyon > <christophe.l...@linaro.org> wrote: >> Hi, >> >> This is a followup to PR63304. >> >> As discussed in bugzilla, this patch disables pcrelative_literal_loads >> when -mfix-cortex-a53-843419 (or its default configure option) is >> used. >> >> I copied the behavior of -mfix-cortex-a53-835769 (e.g. in >> aarch64_can_inline_p), and I have tested by building the Linux kernel >> using -mfix-cortex-a53-843419 and checked that >> R_AARCH64_ADR_PREL_PG_HI21 relocations are not emitted anymore (under >> CONFIG_ARM64_ERRATUM_843419). >> >> For reference, this is motivated by: >> https://bugs.linaro.org/show_bug.cgi?id=1994 > > I think we need a bug report for this in the GCC bugzilla targeting > GCC 6 and have a reference to that in addition to PR63304 as this is > broken behaviour in gcc trunk with respect to the erratum fixup. OK, I have opened PR 70113.
> > There are 2 solutions to this - one is to put out address constants in > the large memory model with the mov / movk instruction sequences but > then that wouldn't work with older released kernels and require > changes to the kernel loader and the other being this where we turn on > PC relative literal loads for the erratum fixup. I personally think > that this solution is probably sensible during stage4 but I cannot > approve changes to the AArch64 backend. > > The only question I have about this implementation in the sources > based on a cursory look at the patch is whether this ends up working > reliably with LTO ? > I haven't tested this case. Do you have any testcase in mind to convince yourself & other maintainers? Building the Linux kernel with LTO? Thanks, Christophe. > > regards > Ramana > >> and further details on Launchpad: >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533009 >> >> OK for trunk? >> >> Thanks, >> >> Christophe.
