GNU Binutils 2.33.1 has been released.

Hello Everyone,

We are pleased to announce that version 2.33.1 of the GNU Binutils project sources have been released and are now available for download at:

https://ftp.gnu.org/gnu/binutils
https://sourceware.org/pub/binutils/releases/

The md5sum values are:

    56a3be5f8f8ee874417a4f19ef3f10c8  binutils-2.33.1.tar.bz2
    1a6b16bcc926e312633fcc3fae14ba0a  binutils-2.33.1.tar.gz
    f4e7e023664f087b3017fc42955ebb46  binutils-2.33.1.tar.lz
    9406231b7d9dd93731c2d06cefe8aaf1  binutils-2.33.1.tar.xz

This release contains numerous bug fixes, and also the following new features:

Assembler:

* Adds support for the Arm Scalable Vector Extension version 2 (SVE2) instructions, the Arm Transactional Memory Extension (TME) instructions and the Armv8.1-M Mainline and M-profile Vector Extension (MVE) instructions.

* Adds support for the Arm Cortex-A76AE, Cortex-A77 and Cortex-M35P processors and the AArch64 Cortex-A34, Cortex-A65, Cortex-A65AE, Cortex-A76AE, and Cortex-A77 processors.

* Adds a .float16 directive for both Arm and AArch64 to allow encoding of 16-bit floating point literals.

* For MIPS, Add -m[no-]fix-loongson3-llsc option to fix (or not) Loongson3 LLSC Errata. Add a --enable-mips-fix-loongson3-llsc=[yes|no] configure time option to set the default behavior. Set the default if the configure option is not used to "no".

Linker:

* The Cortex-A53 Erratum 843419 workaround now supports a choice of which workaround to use. The option --fix-cortex-a53-843419 now takes an optional argument --fix-cortex-a53-843419[=full|adr|adrp] which can be used to force a particular workaround to be used. See --help for AArch64 for more details.

* Add support for GNU_PROPERTY_AARCH64_FEATURE_1_BTI and GNU_PROPERTY_AARCH64_FEATURE_1_PAC in ELF GNU program properties in the AArch64 ELF linker.

* Add -z force-bti for AArch64 to enable GNU_PROPERTY_AARCH64_FEATURE_1_BTI on output while warning about missing GNU_PROPERTY_AARCH64_FEATURE_1_BTI on inputs and use PLTs protected with BTI.

* Add -z pac-plt for AArch64 to pick PAC enabled PLTs.

Utilities:

* Add --source-comment[=<txt>] option to objdump which if present, provides a prefix to source code lines displayed in a disassembly.

* Add --set-section-alignment <section-name>=<power-of-2-align> option to objcopy to allow the changing of section alignments.

* Add --verilog-data-width option to objcopy for verilog targets to control width of data elements in verilog hex format.

* The separate debug info file options of readelf (--debug-dump=links and --debug-dump=follow) and objdump (--dwarf=links and --dwarf=follow-links) will now display and/or follow multiple links if more than one are present in a file. (This usually happens when gcc's -gsplit-dwarf option is used).

In addition objdump's --dwarf=follow-links now also affects its other display options, so that for example, when combined with --syms it will cause the symbol tables in any linked debug info files to also be displayed. In addition when combined with --disassemble the --dwarf= follow-links option will ensure that any symbol tables in the linked files are read and used when disassembling code in the main file.

* Add support for dumping types encoded in the Compact Type Format to objdump and readelf.

Our thanks go out to all of the binutils contributors, past and present, for helping to make this release possible.

Note in case you are wondering about what happened to the 2.33 release, it is stuck pending the resolution of an issue with the keys used to sign the release. Once this is resolved the 2.33 tarballs will be uploaded, even though they will now be slightly out of date.

Cheers
Nick Clifton
Binutils Chief Maintainer.

Hi Romain,

What's the easiest way for me to reproduce this?

I've tried

git clone https://github.com/RomainNaour/buildroot.git buildroot cd buildroot
git checkout binutils-2.33.1

curl https://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/build_fragments/armv7-eabihf--uclibc--bleeding-edge-2018.11-1.defconfig > .config

make olddefconfig
make -j

but All I keep hitting are options mismatch in gmp.

Thanks,
Tamar

Quoted 41 lines

-----Original Message-----
From: Nick Clifton <[email protected]>
Sent: Monday, October 14, 2019 6:45 AM
To: Romain Naour <[email protected]>; Tamar Christina <[email protected]>
Cc: binutils at sourceware.org; buildroot <[email protected]>
Subject: Re: GNU Binutils 2.33.1 has been released.

Hi Romain,

Quoted 7 lines

I tested this new version using toolchain-builder project [1] and discovered some regressions on arm cortex-m4 and SH4 architectures.

There is a segfault in elf2flt while building busybox:
"ld (ld-elf2flt):
/builds/kubu93/toolchains-builder/build/opt/armv7m--uclibc--bleeding-e dge-2/arm-buildroot-uclinux-uclibcgnueabi/bin/elf2flt

Hmm, that is worrying, but I suppose that it could be a bug in elf2flt rather than the binutils. Maybe...

Is this problem specific to the ARM architecture ? (Ie does elf2flt work when compiled and run for other architecures ?) If so, then I would suspect a problem with the changes to the ARM specific code in the BFD library, and I would probably ask one of the ARM regulars to take a look. (Hi Tamar...)

Are you able to find out where the segmentation fault is occurring ? Is it inside the BFD library somewhere ?

Quoted 4 lines

- sh4 [4]: (sh4, binutils 2.33.1, kernel headers 4.19.79, Glibc | uClibc-ng | musl, Qemu 3.1)

The system doesn't boot under Qemu.

*sigh* This one will probably be even harder to investigate. Not being familiar with Qemu, I do not what the best approach would be. Can we get it to tell us why the boot fails ? Does it think that a binary is invalid somehow ?

Cheers
Nick

Hi Romain,

Thanks I was able to reproduce the segfault using that config.

I believe this is a bug in elf2flt. Particularly the segfault happens here https://github.com/uclinux-dev/elf2flt/blob/master/elf2flt.c#L1464
when dereferencing r_mem.

r_mem is invalid because of https://github.com/uclinux-dev/elf2flt/blob/master/elf2flt.c#L532 which does

r_mem = sectionp + q->address;

here sectionp is invalid because of this code https://github.com/uclinux-dev/elf2flt/blob/master/elf2flt.c#L424

The section this is failing on is

$26 = {
name = 0x55a717912241 ".ARM.exidx"

.ARM.exidx is a RO data section which will get placed in the same segment as the text section and BFD usually places it after the text section, however the code in elf2flt.c does

if ((!pic_with_got || ALWAYS_RELOC_TEXT) && (a->flags & SEC_CODE))

	sectionp = text + (a->vma - text_vma);
else if (a->flags & SEC_DATA)
	sectionp = data + (a->vma - data_vma);

Which will incorrectly map it to data. Essentially it's overriding a random point in the data section. Changing that code to map SEC_READONLY | SEC_DATA to text makes it compile and generate an image as expected. I did not try running it.

I think this was broken before already, but you wouldn't really notice it unless you actually had some stack traces to print.

Regards,
Tamar

Quoted 123 lines

-----Original Message-----
From: Romain Naour <[email protected]>
Sent: Monday, October 14, 2019 4:12 PM
To: Tamar Christina <[email protected]>; nickc at redhat.com
Cc: binutils at sourceware.org; buildroot <[email protected]>; nd <[email protected]>
Subject: Re: GNU Binutils 2.33.1 has been released.

Hi Tamar, Nick,

Le 14/10/2019 ? 15:27, Tamar Christina a ?crit?:

Quoted 9 lines

Hi Romain,

What's the easiest way for me to reproduce this?

I've tried

git clone https://github.com/RomainNaour/buildroot.git buildroot cd buildroot
git checkout binutils-2.33.1

This is the correct way to reproduce it :)

Quoted 5 lines

curl
https://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eab
ihf/build_fragments/armv7-eabihf--uclibc--bleeding-edge-2018.11-1.defc onfig > .config

This defconfig was used to only build the 2018.11-1 bleeding-edge toolchain.

Can you use the following defconfig ?
I'm able to reproduce it on my host

BR2_arm=y
BR2_cortex_m4=y BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/stm32f469- disco/patches"
BR2_KERNEL_HEADERS_4_19=y BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
BR2_PTHREAD_DEBUG=y
BR2_BINUTILS_VERSION_2_33_X=y
BR2_GCC_VERSION_9_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.11" BR2_LINUX_KERNEL_DEFCONFIG="stm32" BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="$(LINUX_DIR)/arch/arm/c onfigs/dram_0x00000000.config" BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y BR2_LINUX_KERNEL_IMAGE_TARGET_NAME="xipImage" BR2_LINUX_KERNEL_DTS_SUPPORT=y BR2_LINUX_KERNEL_INTREE_DTS_NAME="stm32f469-disco" BR2_PACKAGE_BUSYBOX_CONFIG="package/busybox/busybox- minimal.config"
BR2_TARGET_ROOTFS_INITRAMFS=y
# BR2_TARGET_ROOTFS_TAR is not set BR2_TARGET_AFBOOT_STM32=y
BR2_PACKAGE_HOST_OPENOCD=y

This defconfig was created by merging the two defconfig from [1]. The first one is used to build the toolchain.
The second one is used to build a kernel + the rootfs using the toolchain previously generated.

[1] https://gitlab.com/kubu93/toolchains-builder/-/jobs/319395300

Best regards,
Romain

Quoted 47 lines

make olddefconfig
make -j

but All I keep hitting are options mismatch in gmp.

Thanks,
Tamar

Quoted 39 lines

-----Original Message-----
From: Nick Clifton <[email protected]>
Sent: Monday, October 14, 2019 6:45 AM
To: Romain Naour <[email protected]>; Tamar Christina <[email protected]>
Cc: binutils at sourceware.org; buildroot <[email protected]>
Subject: Re: GNU Binutils 2.33.1 has been released.

Hi Romain,

Quoted 7 lines

I tested this new version using toolchain-builder project [1] and discovered some regressions on arm cortex-m4 and SH4 architectures.

There is a segfault in elf2flt while building busybox:
"ld (ld-elf2flt):
/builds/kubu93/toolchains-builder/build/opt/armv7m--uclibc--bleeding -e dge-2/arm-buildroot-uclinux-uclibcgnueabi/bin/elf2flt

Hmm, that is worrying, but I suppose that it could be a bug in elf2flt rather than the binutils. Maybe...

Is this problem specific to the ARM architecture ? (Ie does elf2flt work when compiled and run for other architecures ?) If so, then I would suspect a problem with the changes to the ARM specific code in the BFD library, and I would probably ask one of the ARM regulars to take a look. (Hi Tamar...)

Are you able to find out where the segmentation fault is occurring ? Is it inside the BFD library somewhere ?

Quoted 4 lines

- sh4 [4]: (sh4, binutils 2.33.1, kernel headers 4.19.79, Glibc | uClibc-ng | musl, Qemu 3.1)

The system doesn't boot under Qemu.

*sigh* This one will probably be even harder to investigate. Not being familiar with Qemu, I do not what the best approach would be. Can we get it to tell us why the boot fails ? Does it think that a binary is

invalid somehow ?

Quoted 3 lines

Quoted 3 lines

Cheers
Nick

Hi Romain,

Quoted 6 lines

I tested this new version using toolchain-builder project [1] and discovered some regressions on arm cortex-m4 and SH4 architectures.

There is a segfault in elf2flt while building busybox:
"ld (ld-elf2flt):
/builds/kubu93/toolchains-builder/build/opt/armv7m--uclibc--bleeding-edge-2/arm-buildroot-uclinux-uclibcgnueabi/bin/elf2flt

Hmm, that is worrying, but I suppose that it could be a bug in elf2flt rather than the binutils. Maybe...

Is this problem specific to the ARM architecture ? (Ie does elf2flt work when compiled and run for other architecures ?) If so, then I would suspect a problem with the changes to the ARM specific code in the BFD library, and I would probably ask one of the ARM regulars to take a look. (Hi Tamar...)

Are you able to find out where the segmentation fault is occurring ? Is it inside the BFD library somewhere ?

Quoted 6 lines

- sh4 [4]: (sh4, binutils 2.33.1, kernel headers 4.19.79, Glibc | uClibc-ng | musl, Qemu 3.1)

The system doesn't boot under Qemu.

*sigh* This one will probably be even harder to investigate. Not being familiar with Qemu, I do not what the best approach would be. Can we get it to tell us why the boot fails ? Does it think that a binary is invalid somehow ?

Cheers
Nick