This is the mail archive of the
mailing list for the binutils project.
Re: [Patch, AArch64, BFD, LD] [2.24] Cortex-A53 erratum 835769 linker workaround.
- From: Tristan Gingold <gingold at adacore dot com>
- To: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- Cc: Tejas Belagod <tejas dot belagod at arm dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Date: Fri, 24 Oct 2014 12:45:15 +0200
- Subject: Re: [Patch, AArch64, BFD, LD] [2.24] Cortex-A53 erratum 835769 linker workaround.
- Authentication-results: sourceware.org; auth=none
- References: <5447BA3A dot 9070308 at arm dot com> <CAFqB+Pw=vv0mxry=xT8djevdvPbKYbx4unS+mMo9b3tUGtCNgg at mail dot gmail dot com>
> On 24 Oct 2014, at 12:38, Marcus Shawcroft <firstname.lastname@example.org> wrote:
> On 22 October 2014 15:07, Tejas Belagod <email@example.com> wrote:
>> Some early revisions of the Cortex-A53 have an erratum (835769) whereby
>> it is possible for a 64-bit multiply-accumulate instruction in AArch64 state
>> to generate an incorrect result. The details are quite complex and hard to
>> determine statically, since branches in the code may exist in some
>> circumstances, but all cases end with a memory (load, store, or
>> prefetch) instruction followed immediately by the multiply-accumulate
>> We employ a linker patching technique, whereby we move the potentially
>> affected multiply-accumulate instruction into a patch region and
>> replace the original instruction with a branch to the patch.
>> This patch achieves the linker patch. Also, a patch to turn this on from the
>> compiler driver has been submitted independently to the gcc lists.
>> The fix is disabled by default and can be turned on by the
>> --fix-cortex-a53-835769 linker option.
>> Tested on aarch64-none-linux-gnu (and bootstrap with the option) and built
>> and run various large benchmarks with it.
>> Ok for 2.24?
> This should be back ported. However, with 2.25 imminent I want to
> make sure 2.25 gets back ported before/at the same time as 2.24. I'd
> like an explicit OK from Tristan for the back port to 2.25.
Yes, ok for backport.