= Proposed System Wide Change: Binutils 2.31 = https://fedoraproject.org/wiki/Changes/BINUTILS231
Owner(s): * Nick Clifton <nickc at redhat dot com>
Rebase the binutils package from version 2.30 to version 2.31.
== Detailed description == Switch the binutils package from being based on the 2.30 release of the FSF binutils to being based on the 2.31 release. This release will bring in numerous bug fixes, as well as the following new features:
The linker can now put all code and read-only data sections into a separate segment with only READ and EXECUTE permissions. All writable data can be placed into a separate segment with READ and WRITE permissions. This makes programs larger, but safer. The linker's behaviour can be controlled via a command line option, and the default set by a configure option.
The assembler can generate build notes for any input files which do not contain their own notes. Again this is controlled via a command line option whose default is set by a configure option.
The x86 assembler supports a new -O[2|s] command-line option to enable alternate, shorter instruction encoding. It also supports a ,nop pseudo-op to simplify the insertion of NOP instruction sequences.
The AArch64 assembler will now warn a combintation of an instruction and a register name are invalid. The AArch64 disassembler will now also flag inconsistent instruction encodings.
The "ar" program will now accept an "O" modifier to its command line, which causes the offsets of members within the archive to be displayed alongside the other information.
== Scope == * Proposal owners: Change the source parameter in the binutils.spec rpm and adjust the local patches to take account of the bugs that are now already fixed.This should be followed by a mass rebuild in order for the changes to be noticed across the system.
* Other developers: No other work should be necessary. Once the rebase is in place and the buildroot contains the new binutils its use should be automatic.It is possible that the new linker feature might prove to be problematic forsome packages, although no such problems are anticipated. If this doeshappen however the package maintainers can add a command line optionto disable the new linker feature.
* Release engineering: https://pagure.io/releng/issue/7573
** List of deliverables: Just the binutils package.
* Policies and guidelines: No updates needed.
* Trademark approval: N/A (not needed for this Change)
On Thu, Jun 14, 2018 at 05:16:31PM +0200, Jan Kurik wrote:
The linker can now put all code and read-only data sections into a separate segment with only READ and EXECUTE permissions. All writable data can be placed into a separate segment with READ and WRITE permissions. This makes programs larger, but safer. The linker's behaviour can be controlled via a command line option, and the default set by a configure option.
Will this configuration option be switched on in Fedora?
Switch the binutils package from being based on the 2.30 release of the FSF binutils to being based on the 2.31 release. This release will bring in numerous bug fixes, as well as the following new features:
Do you foresee any significant issues with this version upgrade in the mass rebuild? Anything in particular that maintainers and upstreams should looks at?
Zbyszek
On Mon, Jun 18, 2018 at 09:12:35AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jun 14, 2018 at 05:16:31PM +0200, Jan Kurik wrote:
The linker can now put all code and read-only data sections into a separate segment with only READ and EXECUTE permissions. All writable data can be placed into a separate segment with READ and WRITE permissions. This makes programs larger, but safer. The linker's behaviour can be controlled via a command line option, and the default set by a configure option.
Will this configuration option be switched on in Fedora?
Switch the binutils package from being based on the 2.30 release of the FSF binutils to being based on the 2.31 release. This release will bring in numerous bug fixes, as well as the following new features:
Do you foresee any significant issues with this version upgrade in the mass rebuild? Anything in particular that maintainers and upstreams should looks at?
Zbyszek
Also, what is the relationship between https://fedoraproject.org/wiki/Changes/BINUTILS230 and https://fedoraproject.org/wiki/Changes/BINUTILS231 ?
Zbyszek
Hi Zbigniew,
Do you foresee any significant issues with this version upgrade in the mass rebuild?
No. I am currently testing the 2.31 sources on the FSF branch, but so far everything looks good.
Anything in particular that maintainers and upstreams should looks at?
I hope not. There have been problems in the past when rebasing the binutils, so I cannot guarantee that there will be no issues, but I will do my best to make sure that the change does not cause any problems, and that maintainers and upstreams do not even know that it has happened.
Also, what is the relationship between https://fedoraproject.org/wiki/Changes/BINUTILS230 and https://fedoraproject.org/wiki/Changes/BINUTILS231
BINUTILS230 was the change request to bring in FSF binutils 2.30. This is the version that is currently used in rawhide.
BINUTILS231 is the change request to bring in FSF binutils 2.31. The 2.31 release has not actually happened yet - it is scheduled for July 7 - but if it does happen in time then I would like to get it into rawhide before the mass rebuild happens. Then if there are any problems they should show up quickly.
Cheers Nick
On Mon, Jun 25, 2018 at 10:47:04AM +0100, Nick Clifton wrote:
Hi Zbigniew,
Do you foresee any significant issues with this version upgrade in the mass rebuild?
No. I am currently testing the 2.31 sources on the FSF branch, but so far everything looks good.
Anything in particular that maintainers and upstreams should looks at?
I hope not. There have been problems in the past when rebasing the binutils, so I cannot guarantee that there will be no issues, but I will do my best to make sure that the change does not cause any problems, and that maintainers and upstreams do not even know that it has happened.
OK, good to hear that.
Also, what is the relationship between https://fedoraproject.org/wiki/Changes/BINUTILS230 and https://fedoraproject.org/wiki/Changes/BINUTILS231
BINUTILS230 was the change request to bring in FSF binutils 2.30. This is the version that is currently used in rawhide.
BINUTILS231 is the change request to bring in FSF binutils 2.31. The 2.31 release has not actually happened yet - it is scheduled for July 7
- but if it does happen in time then I would like to get it into rawhide
before the mass rebuild happens. Then if there are any problems they should show up quickly.
But changes are specific to a Fedora release. If users see both changes in the release notes for F29 they will be justifiably confused. So I think BINUTILS230 should be automatically dropped (superseded) if BINUTILS231 makes it into F29.
Zbyszek
Hi Zbigniew,
Also, what is the relationship between https://fedoraproject.org/wiki/Changes/BINUTILS230 and https://fedoraproject.org/wiki/Changes/BINUTILS231
BINUTILS230 was the change request to bring in FSF binutils 2.30. This is the version that is currently used in rawhide.
BINUTILS231 is the change request to bring in FSF binutils 2.31. The 2.31 release has not actually happened yet - it is scheduled for July 7
- but if it does happen in time then I would like to get it into rawhide
before the mass rebuild happens. Then if there are any problems they should show up quickly.
But changes are specific to a Fedora release. If users see both changes in the release notes for F29 they will be justifiably confused. So I think BINUTILS230 should be automatically dropped (superseded) if BINUTILS231 makes it into F29.
Oh, right, now I understand. I agree, we should drop BINUTILS230 if BINUTUILS231 makes it in.
Cheers Nick