On Wed, Jun 28, 2017 at 2:02 AM, Kugan Vivekanandarajah <kugan.vivekanandara...@linaro.org> wrote: > Hi Ramana, > > On 27 June 2017 at 18:01, Ramana Radhakrishnan > <ramana.radhakrish...@foss.arm.com> wrote: >> On 27/06/17 02:20, Kugan Vivekanandarajah wrote: >>> >>> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00614.html added this >>> workaround to get kernel building with when TARGET_FIX_ERR_A53_843419 >>> is enabled. >>> >>> This was added to support building kernel loadable modules. In kernel, >>> when CONFIG_ARM64_ERRATUM_843419 is selected, the relocation needed >>> for ADRP/LDR (R_AARCH64_ADR_PREL_PG_HI21 and >>> R_AARCH64_ADR_PREL_PG_HI21_NC are removed from the kernel to avoid >>> loading objects with possibly offending sequence). Thus, it could only >>> support pc relative literal loads. >>> >>> However, the following patch was posted to kernel to add >>> -mpc-relative-literal-loads >>> http://www.spinics.net/lists/arm-kernel/msg476149.html >>> >>> -mpc-relative-literal-loads is unconditionally added to the kernel >>> build as can be seen from: >>> https://github.com/torvalds/linux/blob/master/arch/arm64/Makefile >>> >>> Therefore this patch removes the hunk so that applications like >>> SPECcpu2017's 521/621.wrf can be built (with LTO in this case) without >>> -mno-pc-relative-literal-loads >> >> >> Is that because your compiler has defaulted to -mpc-relative-literal-loads >> because it has the workaround enabled by default ? I'm curious as to why >> others haven't seen this issue. >> > > If TARGET_FIX_ERR_A53_843419 is selected, compiler defaults to > -mpc-relative-literal-loads unless we explicitly specify > -mno-pc-relative-literal-loads. Linaro toolchain is built with > TARGET_FIX_ERR_A53_843419.
That explains why we haven't been hit by this issue in our builds of SPEC2017 even though I don't think we've done any lto builds recently., > > This linking of TARGET_FIX_ERR_A53_843419 and > -mpc-relative-literal-loads should now be relaxed since the kernel > explicitly uses -mpc-relative-literal-loads. > > This 1MiB issue should be very rarely seen even before you fixed it. > This particular issue maybe, but the original patch was put in because we had a number of users complaining about functions > 1MiB especially with autogenerated code. regards Ramana > Thanks, > Kugan > > >> regards >> Ramana