| Message ID | 20171115213428.22559-10-samitolvanen@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Nov 15, 2017 at 01:34:19PM -0800, Sami Tolvanen wrote: > Some versions of GNU gold are known to produce broken code with > --fix-cortex-a53-843419 as explained in this bug: > > https://sourceware.org/bugzilla/show_bug.cgi?id=21491 > > If ARM64_ERRATUM_843419 is disabled and we're using GNU gold, pass > --no-fix-cortex-a53-843419 to the linker to ensure the erratum fix is not > used even if the linker is configured to enable it by default. But if ARM64_ERRATUM_843419 is enabled, we'll go ahead and generate broken code? Will
On Thu, Nov 16, 2017 at 11:47:23AM +0000, Will Deacon wrote: > But if ARM64_ERRATUM_843419 is enabled, we'll go ahead and generate > broken code? This bug has been fixed in all current versions of GNU gold, but of course, if someone is using a broken linker, it will generate broken code. We can't do anything about that in the kernel. The reason for this patch is that the linker can be configured to enable the erratum fix by default, and we must explicitly disable it if we don't want the fix, whether it's because of a broken linker, or in our case, because of issues with kernel modules. Sami
On Thu, Nov 16, 2017 at 08:35:49AM -0800, Sami Tolvanen wrote: > On Thu, Nov 16, 2017 at 11:47:23AM +0000, Will Deacon wrote: > > But if ARM64_ERRATUM_843419 is enabled, we'll go ahead and generate > > broken code? > > This bug has been fixed in all current versions of GNU gold, but of > course, if someone is using a broken linker, it will generate broken > code. We can't do anything about that in the kernel. However, we could instead check ld-version, produce a warning, and abort the build in such cases. Which would be better than silently producing a kernel that won't work correctly. Thanks, Mark.
On Mon, Nov 20, 2017 at 02:47:20PM +0000, Mark Rutland wrote: > However, we could instead check ld-version, produce a warning, and > abort the build in such cases. I believe the version number of gold didn't change in binutils 2.28.1, where this was fixed, but we could certainly warn about older versions of gold. Sami
On Mon, Nov 20, 2017 at 12:35:49PM -0800, Sami Tolvanen wrote: > On Mon, Nov 20, 2017 at 02:47:20PM +0000, Mark Rutland wrote: > > However, we could instead check ld-version, produce a warning, and > > abort the build in such cases. > > I believe the version number of gold didn't change in binutils 2.28.1, > where this was fixed, but we could certainly warn about older versions > of gold. If that's the case, can we mandate gold version > 2.28.1? The latest version seems to be 2.29.1, so there's at least one (hopefully) working release. That might rule out a few working gold binaries, but it would save on unwelcome surprises. Thanks, Mark.
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 6059c8169513..ca700b201736 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -30,6 +30,11 @@ LDFLAGS_vmlinux += --fix-cortex-a53-843419 endif endif +ifeq ($(CONFIG_ARM64_ERRATUM_843419),) +# https://sourceware.org/bugzilla/show_bug.cgi?id=21491 +LDFLAGS_GOLD += --no-fix-cortex-a53-843419 +endif + KBUILD_DEFCONFIG := defconfig # Check for binutils support for specific extensions
Some versions of GNU gold are known to produce broken code with --fix-cortex-a53-843419 as explained in this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21491 If ARM64_ERRATUM_843419 is disabled and we're using GNU gold, pass --no-fix-cortex-a53-843419 to the linker to ensure the erratum fix is not used even if the linker is configured to enable it by default. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> --- arch/arm64/Makefile | 5 +++++ 1 file changed, 5 insertions(+)