[Buildroot] GNU Binutils 2.33.1 has been released.

[Buildroot] GNU Binutils 2.33.1 has been released.

[Romain Naour]

Hi Nick, All,

Le 12/10/2019 ? 17:01, Nick Clifton a ?crit?:
> 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

Thanks for the release.

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

See [1] for the smoke test results (please ignore aarch64--musl issue):

- armv7m [2]: (arm cortex-m4, GCC 9.2, binutils 2.33.1, kernel headers 4.19.79,
uClibc-ng 1.0.31)

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
terminated with signal 11 [Segmentation fault], core dumped"

The build succeed using Binutils 2.32 [3].

- 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.

The system boot using Binutils 2.32 [5]

Here is my Buildroot branch containing the patch adding binutils 2.33.1:
https://github.com/RomainNaour/buildroot/tree/binutils-2.33.1

For now I didn't investigated further.

Thought ?

[1] https://gitlab.com/kubu93/toolchains-builder/pipelines/88475734
[2] https://gitlab.com/kubu93/toolchains-builder/-/jobs/319395300
[3] https://gitlab.com/kubu93/toolchains-builder/-/jobs/319412583
[4] https://gitlab.com/kubu93/toolchains-builder/-/jobs/319395346
    https://gitlab.com/kubu93/toolchains-builder/-/jobs/319395347
    https://gitlab.com/kubu93/toolchains-builder/-/jobs/319395348
[5] https://gitlab.com/kubu93/toolchains-builder/pipelines/88482917

> 
> 
>   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.
> 

[Buildroot] GNU Binutils 2.33.1 has been released.

[Romain Naour]

Hi Tamar, Nick,

Le 14/10/2019 ? 15:27, Tamar Christina a ?crit?:
> 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 :)

> 
>     curl https://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/build_fragments/armv7-eabihf--uclibc--bleeding-edge-2018.11-1.defconfig > .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/configs/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

>     make olddefconfig
>     make -j
> 
> but All I keep hitting are options mismatch in gmp.
> 
> Thanks,
> Tamar
> 
>> -----Original Message-----
>> From: Nick Clifton <nickc@redhat.com>
>> Sent: Monday, October 14, 2019 6:45 AM
>> To: Romain Naour <romain.naour@gmail.com>; Tamar Christina
>> <Tamar.Christina@arm.com>
>> Cc: binutils at sourceware.org; buildroot <buildroot@buildroot.org>
>> Subject: Re: GNU Binutils 2.33.1 has been released.
>>
>> Hi Romain,
>>
>>> 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 ?
>>
>>
>>> - 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

[Buildroot] GNU Binutils 2.33.1 has been released.

[Romain Naour]

Hi Nick,

Le 14/10/2019 ? 12:44, Nick Clifton a ?crit?:
> Hi Romain,
> 
>> 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...

Probably, elf2flt is testing with binutils up to 2.31.1.
We use the latest git version.

> 
> 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...)

I can't say if it's specific to the ARM architecture. elf2flt is only used when
we use FLAT binary format. This is only the case in Buildroot for the ARM
cortex-m4 architecture.

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

For now, I just reproduced on gitlab yesterday and reproduced locally today.

The command line is https://pastebin.com/s9hfWpbE

> 
> 
>> - 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 ?

I tried to reproduce but nothing appear on the screen, not even a initial boot
from the kernel...
I can try to use git bisect between binutils 2.32 and 2.33.1, but it will take a
lot of time.

Best regards,
Romain

> 
> Cheers
>   Nick
> 

[Buildroot] GNU Binutils 2.33.1 has been released.

[Romain Naour]

Hi Tamar,

Le 15/10/2019 ? 15:38, Tamar Christina a ?crit?:
> 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.

Thanks for the investigation, I did the change you suggested and indeed busybox
build correctly and the image is generated as expected.
But I don't have the hardware to test it.

The best I can do is building for all architectures supported by Buildroot and
do a runtime test on the target I have (x86, ARM, aarch64).
The toolchain-builder project is testing with Qemu when a target emulation is
available.

But for this specific case, we don't have such Qemu support.

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

Ok, I'll create an issue on elf2flt github.

Best regards,
Romain

> 
> Regards,
> Tamar
> 
>> -----Original Message-----
>> From: Romain Naour <romain.naour@gmail.com>
>> Sent: Monday, October 14, 2019 4:12 PM
>> To: Tamar Christina <Tamar.Christina@arm.com>; nickc at redhat.com
>> Cc: binutils at sourceware.org; buildroot <buildroot@buildroot.org>; nd
>> <nd@arm.com>
>> Subject: Re: GNU Binutils 2.33.1 has been released.
>>
>> Hi Tamar, Nick,
>>
>> Le 14/10/2019 ? 15:27, Tamar Christina a ?crit?:
>>> 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 :)
>>
>>>
>>>     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
>>
>>>     make olddefconfig
>>>     make -j
>>>
>>> but All I keep hitting are options mismatch in gmp.
>>>
>>> Thanks,
>>> Tamar
>>>
>>>> -----Original Message-----
>>>> From: Nick Clifton <nickc@redhat.com>
>>>> Sent: Monday, October 14, 2019 6:45 AM
>>>> To: Romain Naour <romain.naour@gmail.com>; Tamar Christina
>>>> <Tamar.Christina@arm.com>
>>>> Cc: binutils at sourceware.org; buildroot <buildroot@buildroot.org>
>>>> Subject: Re: GNU Binutils 2.33.1 has been released.
>>>>
>>>> Hi Romain,
>>>>
>>>>> 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 ?
>>>>
>>>>
>>>>> - 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
>