[PATCH] D36742: [LLD][ELF][AArch64] Implement scanner for Cortex-A53 Erratum 843419

[Peter Smith via llvm-commits]

>> At the moment, until https://reviews.llvm.org/D37944 Add support for AArch64 Range Thunks lands the assignAddresses won't be entered. Some merge work will be needed here as Thunks and Errata fixes can impact each other.
>
> How? Can't you always put the errata fixes after all regular code?
>

Not always if the program is large. I've recently been investigating a
problem with the gold implementation of --fix-cortex-a53-843419
(https://sourceware.org/bugzilla/show_bug.cgi?id=20765) in that
program there is over 180 Mb of code (quite a lot for a wiki editor,
but apparently Haskell tends to produce huge binaries) which in effect
means:
~ 128 Mb code
Thunks and errata for first ~128Mb
~ more code
Thunks and errata for next ~128Mb

If these are all in the same OutputSection then adding errata fixes to
the first chunk will affect the ranges of the code after it, which may
need more Thunks. The gold problem is an internal error when that
condition occurs.

>>>> +// This file implements Section Patching for the purpose of working around
>>> Given where this is called you also need to be able to place the
>>>  replacement sequence after all other sections or you will need to
>>>  reevaluate addresses for thunks, no?
>>
>> Yes. At time of writing AArch64 doesn't support thunks, my preference would be to land the range thunks support for AArch64 first (https://reviews.llvm.org/D37944) and then merge this in with some test cases involving range extension thunks.
>
> Sure. Please add it as a dependency to this one.
>

Ok will do.

>>>> +// - The implementation here only supports one patch, the AArch64 Cortex-53
>>>>  +// errata 843419 that affects r0p0, r0p1, r0p2 and r0p4 versions of the core.
>>>>  +// To keep the initial version simple there is no support for multiple
>>>>  +// architectures or selection of different patches.
>>>
>>> BTW, is it public knowledge what uses these versions? I am not sure if
>>> that is something that is present in a few early dev boards or in most
>>> of the phones on the planet.
>>
>> Unfortunately I don't have concrete information, we'd need to know for
>> each phone what SoC it was using, and for each SoC which rev of the
>> Cortex-A53 it was using. What I do know is that it was reproduced in
>> real Android software on enough phones to make the NDK enable the
>> gold/bfd equivalent option by default.
>
> OK, that is plenty. Just add a comment saying it is enabled by default
> on the android ndk.
>

Sure, will do.

> Cheers,
> Rafael