https://sourceware.org/bugzilla/show_bug.cgi?id=21491
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
https://sourceware.org/bugzilla/show_bug.cgi?id=21062
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.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
