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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 15-04-2015 11:39, Maxim Kuvyrkov wrote:
>> 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?
> 

I checked both on x86_64 cross-compile and native aarch64 build and make check 
shows no regression.  I also checked the GLIBC testcase native and saw no
regression (GLIBC used to catch some linking issue in previous work).

I am still grokking the GCC testsuite output, since I am not familiar which
testcases are currently expected to fail in aarch64.  However since backport
only uses already upstream patches, I do not expect much trouble.

> 
> OK, thanks for clearing this up.
> 
> Adhemerval, so the way forward seems to be to push 2.24 version to linaro_binutils-2_24-branch in git.linaro.org/toolchain/binutils-gdb.git repo, and push 2.25 version to upstream binutils-2_25-branch once it is approved by relevant maintainers.
> 

Fair enough, I will update Linaro branch and prepare the 2.25 backport patches
to upstream.


> Thank you,
> 
> --
> Maxim Kuvyrkov
> www.linaro.org
>