This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 15/04/15 17:22, Tristan Gingold wrote:

On 15 Apr 2015, at 10:39, Maxim Kuvyrkov <> wrote:


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).


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:

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.



[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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]