This is the mail archive of the
binutils@sourceware.org
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 <adhemerval.zanella@linaro.org> wrote:
>
> Hi,
>
> I have prepared a patchset to backport the workaround for cortex-a53 erratum 843419 [1]
> 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?
>
> [1] https://sourceware.org/ml/binutils/2015-03/msg00445.html
Hi Tristan,
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.]
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