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: Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Tristan Gingold <gingold at adacore dot com>
- Cc: Binutils <binutils at sourceware dot org>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>
- Date: Wed, 15 Apr 2015 17:39:40 +0300
- 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>
> On Apr 14, 2015, at 1:34 AM, Adhemerval Zanella <email@example.com> wrote:
> I have prepared a patchset to backport the workaround for cortex-a53 erratum 843419 
> to 2.24 branch and I would like to know which the correct procedures to push them
> upstream. They backport compromise the following patches:
> 6186551 Implement branch over stub section
> d9ced15 Remove padding before stub sections
> 357d152 Adjust veneer count
> fc6d53b Factor out _bfd_aarch64_get_stub_for_link_section.
> 30068a6 Refactor section_group representation
> 5421cc6 Refactor generation of 835769 workaround stubs.
> e572930 Use _bfd_aarch64_add_stub_entry_in_group
> c53ed7c [OBV] Fix build -- missing ';'
> 35fee8b Factor out _bfd_aarch64_erratum_835769_stub_name
> 13f622e Factor out _bfd_aarch64_resize_stubs()
> 6658567 Factor stub creation code into _bfd_aarch64_create_stub_section
> ef85752 Factor out common behaviour between elf_aarch64_create_or_find_stub_sec
> 2144188 Flip sense of erratum_835769_scan
> 4c77202 Drop unused argument to elf_aarch64_create_or_find_stub_sec
> 9b9971a Remove unused variable
> e2cdef4 Remove dead code
> 8ef229f Removing unused functions
> c8f89a3 Remove Load/Store register (unscaled immediate) alias
> 4106101 Workaround for Cortex A53 erratum 843419
> Which minor adjustments. For other GNU project I contribute, GLIBC, it is up to
> release manager to allow or not bugfixes to previous releases. Also, should I send
> the patches upstream for evaluation as usual? Also, should I post in the format
> of list ([xx/xx] ...) or a inline version attached is suffice?
>  https://sourceware.org/ml/binutils/2015-03/msg00445.html
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. Would you please confirm whether or not it is possible to push bug fixes to those branches?
[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?