Changes/BINUTILS231

Binutils 2.31

Summary

Rebase the binutils package from version 2.30 to version 2.31.

Owner

• Name: Nick Clifton [1]
• Email: nickc@redhat.com
• Release notes owner:

Current status

• Targeted release: Fedora 29
• Last updated: 2018-06-28
• Tracker bug: #1596190
• Release Notes tracking: #187

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.

Benefit to Fedora

The main benefit will be the bug fixes and the improvement to the linker. The linker change should make it possible for the loader to mark code segments as read-only, thus improving the safety of the system.

Note - none of these improvements are likely to be noticed by the ordinary user, although developers may notice some improved performance from the linker.

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 for some packages, although no such problems are anticipated. If this does happen however the package maintainers can add a command line option to disable the new linker feature.

• Release engineering: [2]

• • List of deliverables: Just the binutils package.

• Policies and guidelines: No updates needed.

• Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

The binutils are backwards compatible with previous releases, so no changes should be necessary.

How To Test

The binutils package does include its own set of testsuites which check basic functionality. The real test however is by rebuilding other packages which depend upon the binutils, or more likely, upon gcc. If these packages continue to work then the binutils update has not broken anything.

User Experience

The change should not be noticeable to the user.

Dependencies

This update has no hard dependencies on any other package. There are other packages that do depend upon the binutils however. Most notably gcc and redhat-rpm-config.

Contingency Plan

• Contingency mechanism:

Revert to the 2.30 binutils as currently used in rawhide. This work can be done by me, should it prove necessary.

• Contingency deadline: Beta Freeze
• Blocks release? No
• Blocks product? None

Documentation

Documentation is not currently available, due to the fact that the 2.31 release has not yet been created. (It is hoped that the release will happen before the Fedora 29 mass rebuid on 11 July).

Release Notes

• Release Notes tracking: #187