This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] Backport of workaround for cortex-a53 erratum 843419 to 2.24
- From: Marcus Shawcroft <marcus dot shawcroft at arm dot com>
- To: Tristan Gingold <gingold at adacore dot com>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Binutils <binutils at sourceware dot org>
- Date: Fri, 17 Apr 2015 08:47:07 +0100
- Subject: Re: [RFC] Backport of workaround for cortex-a53 erratum 843419 to 2.24
- Authentication-results: sourceware.org; auth=none
- References: <552C4467 dot 4010800 at linaro dot org> <BF5E2894-266C-4F2B-9E0D-81BC4B4237EC at linaro dot org> <D67B8E15-4530-45E4-A36B-96F231A16036 at adacore dot com>
On 15/04/15 17:22, Tristan Gingold wrote:
On 15 Apr 2015, at 10:39, Maxim Kuvyrkov <email@example.com> 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
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.]
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?
Adhemerval, If you have not seen these posts already, you might find