[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gold/21491] New: --fix-cortex-a53-843419 Errata workaround can prod

From: peter.smith at linaro dot org
Subject: [Bug gold/21491] New: --fix-cortex-a53-843419 Errata workaround can produce broken images
Date: Mon, 15 May 2017 10:48:02 +0000


            Bug ID: 21491
           Summary: --fix-cortex-a53-843419 Errata workaround can produce
                    broken images
           Product: binutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gold
          Assignee: ccoutant at gmail dot com
          Reporter: peter.smith at linaro dot org
                CC: ian at airs dot com
  Target Milestone: ---

Created attachment 10051
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10051&action=edit
Test case to reproduce the --ffix-cortex-843419 missing immediate

The --fix-cortex-a53-843419 errata workaround extracts a ldr or str instruction
of the form ld/st xt, [xn, #uimm] into an erratum stub. In certain
circumstances the erratum stub extracts the instruction before it has been
relocated leading to a ldr/str instruction in the stub with a 0 immediate,
whereas if the patch were not applied the immediate would be non-0. This is
likely to incorrect program, in our case a segfault at runtime.

The root cause of the problem is when the erratum stubs for an output section
are assigned to an input section from an object that is relocated before the
object that contains the input section that needs the errata fix. In this case
the stub table is relocated when the "owning" section is relocated, which can
be before the section needing the patch is relocated (which updates the stub
table) so the stub table contains the unrelocated instruction bit pattern.

This is most likely (and how we encountered it) with LTO as the ELF object that
comes back from the plugin is added last and has its relocations processed
last. If the .text section from the LTO object needs a patch and the stub table
"owner" is not from that LTO object then we observe the problem.

I've attached a modification of the ld.bfd test erratum843419.s (add an
immediate to extracted instruction) that can trigger this problem with a
somewhat contrived linker script. Check the disassembly with the fix applied
against the patch without the fix applied
Original no fix:
 2001004:       f9008008        str     x8, [x0,#256]
With fix:
 2001004:       14000008        b       2001024 <fn+0x4>
0000000002001020 <fn>:
 2001020:       d65f03c0        ret
 2001024:       f9000008        str     x8, [x0]
 2001028:       17fffff8        b       2001008 <e843419_1+0x10>

Note that the #256 has been lost.

I think that this is important as the android NDK enables the
--fix-cortex-a53-843419 by default so any use of LTO within android is at risk.

I suspect that this may be the root cause of

A possible workaround for LTO builds is to use a linker script and put the
.text section from LTO into its own output section to make sure the owner of
the stub table is the LTO object.

You are receiving this mail because:
You are on the CC list for the bug.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]