Re: [RFC] Backport of workaround for cortex-a53 erratum 843419 to 2.24

[Marcus Shawcroft <marcus dot shawcroft at arm dot com>]

On 15/04/15 17:22, Tristan Gingold wrote:
> > On 15 Apr 2015, at 10:39, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
>
> Hello,
>
> > I am not very familiar with Binutils release branch policies either, but it seems that there have been no commits to either binutils-2_24 or binutils-2_25 branches since they were created.
>
> That's certainly not correct!  Were you looking at a recent binutils-gdb.git pull ?
>
> >   Would you please confirm whether or not it is possible to push bug fixes to those branches?
>
> Sure it is.  Note that this is too late for 2.24: there won't be any new release on that branch, given 2.25 was created.
> For backporting to 2.25, it would be nice to have the OK from an ARM maintainer.  Generally speaking, we only backport regression fixes or safe small improvements (not sure that 'Remove dead code' fit in these criteria).

Hi,

This series of patches work around an issue in certain versions of a 
particular CPU by detecting and removing various combinations of 
instructions.

I previously posted backport recipes for 2.25 and 2.24 here:

https://sourceware.org/ml/binutils/2015-03/msg00446.html
https://sourceware.org/ml/binutils/2015-04/msg00114.html

The majority of these patches are refactors of some form, cleaning up 
the underlying code and restructuring various interfaces.

My thoughts on back porting are that:

1) These changes are rather more invasive than any other series of 
patches I've seen back ported in binutils.  There is risk associated 
with back porting these patches, (limited to aarch64 target)... that 
said these patches have been used to build AOSP, a substantial portion 
of debian and have been subjected to some testing with llvm, all using 
both the 2.24 and 2.25 recipes linked above.  They have been in trunk 
since 1/4/2015, ~ 3weeks without any issues reported.

2) If we backport then we should not skip versions, it would be bizarre 
if some versions of 2.24 had this feature yet 2.25 did not!

3) There are a number of folks who want to take these patches, back 
porting the patches into the upstream branches will save duplicated effort.

4) Upstream will make no further 2.24 releases. However it is evident 
that there are folks out there who still consume the 2.24 source base. 
Landing the back ports in the 2.24 branch will still save those folks 
duplicated effort, even if we don;t make any further 2.24 releases.

5) I am concerned that back porting these patches creates a situation 
where some variants of a 2.25 (or 2.24) tool chain support this 
workaround and option, while others do not.


I don't really have a good feel for how bad 5) is, but we are in a world 
where there are going to be 2.24 and 2.25 variants deployed that have 
this patch series installed, so I don;t see any benefit in with holding 
them from the upstream branches on those grounds.

On balance, despite initial reservations, I think we should consider 
these backports to 2.25 and 2.24, but I'd like to hear views from other 
folks who have an interest in this series.

Thanks
/Marcus


> Tristan.
>
> > [I think that the answer is "no", and rationale behind it is that various projects check binutils version to see if a particular feature is supported or bug is fixed.  As there is no easy way to identify pre-bug-fix binutils-2_24 from post-bug-fix binutils-2_24, no one should depend on binutils-2_24 to have the bug fix.]
> >
> > Hi Adhemerval,
> >
> > Would you please push the above backport to a branch so that engineers at ARM and anyone else can review and/or test if they want to?
> >
> > How did you test your backports?  Are there any regressions from the patches?  Does the whole toolchain (binutils, gcc, glibc, gdb) build work as expected?
> >
> > Thank you,
> >
> > --
> > Maxim Kuvyrkov
> > www.linaro.org


Adhemerval, If you have not seen these posts already, you might find 
them useful:

https://sourceware.org/ml/binutils/2015-03/msg00446.html
https://sourceware.org/ml/binutils/2015-04/msg00114.html

Cheers
/Marcus