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 Apr 14, 2015, at 1:34 AM, Adhemerval Zanella <> 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]

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

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