GNU Binutils 2.33.1 has been released.

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

GNU Binutils 2.33.1 has been released.

Nick Clifton
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.
Reply | Threaded
Open this post in threaded view
|

Re: GNU Binutils 2.33.1 has been released.

Romain Naour-2
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.
>

Reply | Threaded
Open this post in threaded view
|

Re: GNU Binutils 2.33.1 has been released.

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

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
Reply | Threaded
Open this post in threaded view
|

RE: GNU Binutils 2.33.1 has been released.

Tamar Christina-2
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

> -----Original Message-----
> From: Nick Clifton <[hidden email]>
> Sent: Monday, October 14, 2019 6:45 AM
> To: Romain Naour <[hidden email]>; Tamar Christina
> <[hidden email]>
> Cc: [hidden email]; buildroot <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: GNU Binutils 2.33.1 has been released.

Romain Naour-2
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 <[hidden email]>
>> Sent: Monday, October 14, 2019 6:45 AM
>> To: Romain Naour <[hidden email]>; Tamar Christina
>> <[hidden email]>
>> Cc: [hidden email]; buildroot <[hidden email]>
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: GNU Binutils 2.33.1 has been released.

Romain Naour-2
In reply to this post by Nick Clifton
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
>

Reply | Threaded
Open this post in threaded view
|

RE: GNU Binutils 2.33.1 has been released.

Tamar Christina-2
In reply to this post by Romain Naour-2
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

> -----Original Message-----
> From: Romain Naour <[hidden email]>
> Sent: Monday, October 14, 2019 4:12 PM
> To: Tamar Christina <[hidden email]>; [hidden email]
> Cc: [hidden email]; buildroot <[hidden email]>; nd
> <[hidden email]>
> 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 <[hidden email]>
> >> Sent: Monday, October 14, 2019 6:45 AM
> >> To: Romain Naour <[hidden email]>; Tamar Christina
> >> <[hidden email]>
> >> Cc: [hidden email]; buildroot <[hidden email]>
> >> 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

Reply | Threaded
Open this post in threaded view
|

Re: GNU Binutils 2.33.1 has been released.

Romain Naour-2
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 <[hidden email]>
>> Sent: Monday, October 14, 2019 4:12 PM
>> To: Tamar Christina <[hidden email]>; [hidden email]
>> Cc: [hidden email]; buildroot <[hidden email]>; nd
>> <[hidden email]>
>> 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 <[hidden email]>
>>>> Sent: Monday, October 14, 2019 6:45 AM
>>>> To: Romain Naour <[hidden email]>; Tamar Christina
>>>> <[hidden email]>
>>>> Cc: [hidden email]; buildroot <[hidden email]>
>>>> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: GNU Binutils 2.33.1 has been released.

Romain Naour-2
In reply to this post by Nick Clifton
Hi Nick, All,

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

This issue has been resolved in elf2flt:

https://github.com/uclinux-dev/elf2flt/issues/12

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

For this issue I used git bisect on binutils source between 2.32 and 2.33.
Finally the issue come from this commit [1]:

"PR24311, FAIL: S-records with constructors

Not padding string merge section output to its alignment can cause
failures of the S-record tests when input string merge sections are
padded, since the ELF linker output for the single string section
would shrink compared to the SREC linker output.  That might result in
following sections having different addresses.
On the other hand, padding string merge section output when input
string merge sections are *not* padded can also cause failures, in
this case due to the ELF linker output for the string section being
larger (due to padding) than the SREC linker output.

It would be better to write a more robust test, but it is also nice
to leave input unchanged when no string merges occur."


How to reproduce:

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

   make qemu_sh4_r2d_defconfig
   make menuconfig

   In the toolchain menu, change binutils version to 2.33.1.
   (I used gcc 9.2 for my tests, so you can also set the gcc version to 9.2)

   make

   qemu-system-sh4 -M r2d -kernel output/images/zImage -drive
file=output/images/rootfs.ext2,if=ide,format=raw -append "rootwait root=/dev/sda
console=ttySC1,115200 noiotrap" -serial null -serial stdio -net
nic,model=rtl8139 -net user

The system doesn't boot but if It I revert the commit [1], the system boot.

Since it's a commit not related to sh4, it's weird that is the only affected
architecture.

[1]
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebd2263ba9a9124d93bbc0ece63d7e0fae89b40e

Best regards,
Romain

>
> Cheers
>   Nick
>

Reply | Threaded
Open this post in threaded view
|

Re: GNU Binutils 2.33.1 has been released.

Alan Modra-3
On Sat, Nov 30, 2019 at 12:05:55PM +0100, Romain Naour wrote:
> The system doesn't boot but if It I revert the commit [1], the system boot.
>
> Since it's a commit not related to sh4, it's weird that is the only affected
> architecture.
>
> [1]
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebd2263ba9a9124d93bbc0ece63d7e0fae89b40e

Difference in vmlinux linker map file (I added -Map vmlinux.map to ld
flags) between 2.33.1 and 2.33.1 with [1] reverted is:

                 0x000000008c3ff5b0       0x11 lib/timerqueue.o
  *fill*         0x000000008c3ff5c1        0x3
  .rodata.str1.4
-                0x000000008c3ff5c4      0x13f lib/vsprintf.o
+                0x000000008c3ff5c4      0x140 lib/vsprintf.o
                                         0x1bf (size before relaxing)
-                0x000000008c3ff703                __start_ro_after_init = .
+                0x000000008c3ff704                __start_ro_after_init = .
  *(.data..ro_after_init)
- *fill*         0x000000008c3ff703        0x1
  .data..ro_after_init
                 0x000000008c3ff704       0x1c kernel/ksysfs.o
  .data..ro_after_init

I believe there is a kernel bug in handling of __start_ro_after_init.
If you take a look at kmemleak.c:scan_block you'll see that the start
address is aligned up to a pointer sized boundary.  That's fine, but
scan_large_block calls scan_block repeatedly without first aligning
the start address, with the result that one word is missed from the
scan every MAX_SCAN_SIZE bytes when __start_ro_after_init is not
aligned.  The following untested patch should fix this.
Alternatively, align __start_ro_after_init in the script.

--- mm/kmemleak.c~ 2019-01-17 07:34:38.000000000 +1030
+++ mm/kmemleak.c 2019-12-02 14:33:20.997174278 +1030
@@ -1377,6 +1377,7 @@ static void scan_large_block(void *start
 {
  void *next;
 
+ start = PTR_ALIGN(start, BYTES_PER_POINTER);
  while (start < end) {
  next = min(start + MAX_SCAN_SIZE, end);
  scan_block(start, next, NULL);

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: GNU Binutils 2.33.1 has been released.

Alan Modra-3
On Tue, Dec 03, 2019 at 09:59:48PM +0100, Romain Naour wrote:

> Hi,
>
> Le lun. 2 déc. 2019 à 05:17, Alan Modra <[hidden email]> a écrit :
>
> > On Sat, Nov 30, 2019 at 12:05:55PM +0100, Romain Naour wrote:
> > > The system doesn't boot but if It I revert the commit [1], the system
> > boot.
> > >
> > > Since it's a commit not related to sh4, it's weird that is the only
> > affected
> > > architecture.
> > >
> > > [1]
> > >
> > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebd2263ba9a9124d93bbc0ece63d7e0fae89b40e
> >
> > Difference in vmlinux linker map file (I added -Map vmlinux.map to ld
> > flags) between 2.33.1 and 2.33.1 with [1] reverted is:
> >
> >                  0x000000008c3ff5b0       0x11 lib/timerqueue.o
> >   *fill*         0x000000008c3ff5c1        0x3
> >   .rodata.str1.4
> > -                0x000000008c3ff5c4      0x13f lib/vsprintf.o
> > +                0x000000008c3ff5c4      0x140 lib/vsprintf.o
> >                                          0x1bf (size before relaxing)
> > -                0x000000008c3ff703                __start_ro_after_init =
> > .
> > +                0x000000008c3ff704                __start_ro_after_init =
> > .
> >   *(.data..ro_after_init)
> > - *fill*         0x000000008c3ff703        0x1
> >   .data..ro_after_init
> >                  0x000000008c3ff704       0x1c kernel/ksysfs.o
> >   .data..ro_after_init
> >
> > I believe there is a kernel bug in handling of __start_ro_after_init.
> > If you take a look at kmemleak.c:scan_block you'll see that the start
> > address is aligned up to a pointer sized boundary.  That's fine, but
> > scan_large_block calls scan_block repeatedly without first aligning
> > the start address, with the result that one word is missed from the
> > scan every MAX_SCAN_SIZE bytes when __start_ro_after_init is not
> > aligned.  The following untested patch should fix this.
> > Alternatively, align __start_ro_after_init in the script.
> >
> > --- mm/kmemleak.c~      2019-01-17 07:34:38.000000000 +1030
> > +++ mm/kmemleak.c       2019-12-02 14:33:20.997174278 +1030
> > @@ -1377,6 +1377,7 @@ static void scan_large_block(void *start
> >  {
> >         void *next;
> >
> > +       start = PTR_ALIGN(start, BYTES_PER_POINTER);
> >
>
> scan_large_block is only user when CONFIG_SMP is enabled but it is not in
> the kernel config I'm using
>
> I tested with this patch but the kernel doesn't boot.
>

I built a kernel using your buildroot and binutils-2.33.1 with and
without patch [1].  cmp -l shows 41 bytes different in vmlinux.  These
are in the .notes section (build id), .rodata (date and time string),
.data (date and time string again), and .symtab (the value of
__start_ro_after_init).

Yet you claim that a kernel built with binutils-2.33.1 with patch
[1] reverted works.  Which very likely means your description of how
to reproduce the problem is missing some critical detail.  Have you
compared vmlinux binaries for differences?

>
>         while (start < end) {
> >                 next = min(start + MAX_SCAN_SIZE, end);
> >                 scan_block(start, next, NULL);
> >

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: GNU Binutils 2.33.1 has been released.

Romain Naour-2
Hi,

Le 05/12/2019 à 03:52, Alan Modra a écrit :

> On Tue, Dec 03, 2019 at 09:59:48PM +0100, Romain Naour wrote:
>> Hi,
>>
>> Le lun. 2 déc. 2019 à 05:17, Alan Modra <[hidden email]> a écrit :
>>
>>> On Sat, Nov 30, 2019 at 12:05:55PM +0100, Romain Naour wrote:
>>>> The system doesn't boot but if It I revert the commit [1], the system
>>> boot.
>>>>
>>>> Since it's a commit not related to sh4, it's weird that is the only
>>> affected
>>>> architecture.
>>>>
>>>> [1]
>>>>
>>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebd2263ba9a9124d93bbc0ece63d7e0fae89b40e
>>>
>>> Difference in vmlinux linker map file (I added -Map vmlinux.map to ld
>>> flags) between 2.33.1 and 2.33.1 with [1] reverted is:
>>>
>>>                  0x000000008c3ff5b0       0x11 lib/timerqueue.o
>>>   *fill*         0x000000008c3ff5c1        0x3
>>>   .rodata.str1.4
>>> -                0x000000008c3ff5c4      0x13f lib/vsprintf.o
>>> +                0x000000008c3ff5c4      0x140 lib/vsprintf.o
>>>                                          0x1bf (size before relaxing)
>>> -                0x000000008c3ff703                __start_ro_after_init =
>>> .
>>> +                0x000000008c3ff704                __start_ro_after_init =
>>> .
>>>   *(.data..ro_after_init)
>>> - *fill*         0x000000008c3ff703        0x1
>>>   .data..ro_after_init
>>>                  0x000000008c3ff704       0x1c kernel/ksysfs.o
>>>   .data..ro_after_init
>>>
>>> I believe there is a kernel bug in handling of __start_ro_after_init.
>>> If you take a look at kmemleak.c:scan_block you'll see that the start
>>> address is aligned up to a pointer sized boundary.  That's fine, but
>>> scan_large_block calls scan_block repeatedly without first aligning
>>> the start address, with the result that one word is missed from the
>>> scan every MAX_SCAN_SIZE bytes when __start_ro_after_init is not
>>> aligned.  The following untested patch should fix this.
>>> Alternatively, align __start_ro_after_init in the script.
>>>
>>> --- mm/kmemleak.c~      2019-01-17 07:34:38.000000000 +1030
>>> +++ mm/kmemleak.c       2019-12-02 14:33:20.997174278 +1030
>>> @@ -1377,6 +1377,7 @@ static void scan_large_block(void *start
>>>  {
>>>         void *next;
>>>
>>> +       start = PTR_ALIGN(start, BYTES_PER_POINTER);
>>>
>>
>> scan_large_block is only user when CONFIG_SMP is enabled but it is not in
>> the kernel config I'm using
>>
>> I tested with this patch but the kernel doesn't boot.
>>
>
> I built a kernel using your buildroot and binutils-2.33.1 with and
> without patch [1].  cmp -l shows 41 bytes different in vmlinux.  These
> are in the .notes section (build id), .rodata (date and time string),
> .data (date and time string again), and .symtab (the value of
> __start_ro_after_init).>
> Yet you claim that a kernel built with binutils-2.33.1 with patch
> [1] reverted works.  Which very likely means your description of how
> to reproduce the problem is missing some critical detail.  Have you
> compared vmlinux binaries for differences?
Yes, but I can't explain the difference.
Here is the diff between the output of readelf on two vmlinux (the result is
slightly different, only sections comment, symtab, strtab and shstrtab are changed).

Here is the defconfig I used for both build, using the same Buildroot version.
The only change is the Binutils patch reverting [1].

BR2_sh=y
BR2_GLOBAL_PATCH_DIR="board/qemu/sh4-r2d/patches"
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_19=y
BR2_BINUTILS_VERSION_2_33_X=y
BR2_GCC_VERSION_9_X=y
BR2_TARGET_GENERIC_GETTY_PORT="ttySC1"
BR2_SYSTEM_DHCP="eth0"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/sh4-r2d/linux.config"
BR2_LINUX_KERNEL_ZIMAGE=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set

Can you compare with your defconfig (use make savedefconfig).
Check if binutils 2.33.1 has been used to build the toolchain.

Have you tried to run the system using Qemu and the command line provided
previously?

Otherwise, I don't understand why you can't reproduce the issue.

Best regards,
Romain

>
>>
>>         while (start < end) {
>>>                 next = min(start + MAX_SCAN_SIZE, end);
>>>                 scan_block(start, next, NULL);
>>>
>


sh4-diff.txt (123K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GNU Binutils 2.33.1 has been released.

Alan Modra-3
On Sun, Dec 08, 2019 at 06:12:45PM +0100, Romain Naour wrote:
> Yes, but I can't explain the difference.
> Here is the diff between the output of readelf on two vmlinux (the result is
> slightly different, only sections comment, symtab, strtab and shstrtab are changed).

Whereas in my case, readelf shows just __start_ro_after_init and build
id differing.  The .comment section changing might indicate you are
using different gccs to compile the two vmlinux binaries.

> Check if binutils 2.33.1 has been used to build the toolchain.

Yes, it really was binutils-2.33.1.  After I hacked things around to
get binutils-2.33.1 to build and the first kernel built, I copied
output/build/linux-4.19.16 to somewhere else, ran "make clean" and
removed some .stamp files in order to get the buildroot make to
rebuild the kernel.  I went into the binutils dir, reverted the patch
you identified, ran make and copied ld/ld-new to
output/host/bin/sh4-buildroot-linux-uclibc-ld (and ld.bfd).  Then ran
make at the buildroot top level again to recompile the kernel using
the new ld.  Why did I do things like that?  Because I like to control
exactly what differs between two builds.

> Have you tried to run the system using Qemu and the command line provided
> previously?

Not until now.  I verified that kernels built with binutils-2.33.1
with either the include/arch/vmlinux.lds.h fix or the mm/kmemleak.c
fix fail.

Digging into that, I copied the good linux-4.19.16/vmlinux and built a
zImage from it.  That failed.  So there was another kernel bug.  I see
this in an arch/sh/boot/compressed/vmlinux linker map file:

 *(.rodata.*)
 .rodata.str1.4
                0x000000008c8039a8      0x175 arch/sh/boot/compressed/misc.o
 .rodata..compressed
                0x000000008c803b1d   0x2c4bd5 arch/sh/boot/compressed/piggy.o
                0x000000008c803b1d                input_len
                0x000000008c803b21                _binary_arch_sh_boot_compressed_vmlinux_bin_gz_start
                0x000000008c803b21                input_data
                0x000000008cac86ee                output_len
                0x000000008cac86f2                input_data_end
                0x000000008cac86f2                _binary_arch_sh_boot_compressed_vmlinux_bin_gz_end
                0x000000008cac86f4                . = ALIGN (0x4)

So we have the compressed image sitting at an odd address.  It looks
like the sh uncompressor can't handle that.


Here's the fix then to cure these kernel bugs:

--- ./include/asm-generic/vmlinux.lds.h~ 2019-01-17 07:34:38.000000000 +1030
+++ ./include/asm-generic/vmlinux.lds.h 2019-12-09 11:36:05.778675948 +1030
@@ -306,6 +306,7 @@
  */
 #ifndef RO_AFTER_INIT_DATA
 #define RO_AFTER_INIT_DATA \
+ . = ALIGN(8); \
  __start_ro_after_init = .; \
  *(.data..ro_after_init) \
  __end_ro_after_init = .;

--- arch/sh/boot/compressed/vmlinux.scr~ 2019-01-17 07:34:38.000000000 +1030
+++ arch/sh/boot/compressed/vmlinux.scr 2019-12-09 13:31:03.533135945 +1030
@@ -1,6 +1,6 @@
 SECTIONS
 {
-  .rodata..compressed : {
+  .rodata..compressed : ALIGN(8) {
  input_len = .;
  LONG(input_data_end - input_data) input_data = .;
  *(.data)

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: GNU Binutils 2.33.1 has been released.

Romain Naour-3
Hi,

Sorry for the late reply.

Le 09/12/2019 à 04:39, Alan Modra a écrit :
> On Sun, Dec 08, 2019 at 06:12:45PM +0100, Romain Naour wrote:
>> Yes, but I can't explain the difference.
>> Here is the diff between the output of readelf on two vmlinux (the result is
>> slightly different, only sections comment, symtab, strtab and shstrtab are changed).
>
> Whereas in my case, readelf shows just __start_ro_after_init and build
> id differing.  The .comment section changing might indicate you are
> using different gccs to compile the two vmlinux binaries.

I'm using two different Buildroot's build directories, one to reproduce the
issue and the second one with the patch reverted in Binutils. Indeed I'm using
two different tollchains but build from the same recipe (only the build
directory change). I expected to have the same result for both except for
__start_ro_after_init and build id... good to know.

>
>> Check if binutils 2.33.1 has been used to build the toolchain.
>
> Yes, it really was binutils-2.33.1.  After I hacked things around to
> get binutils-2.33.1 to build and the first kernel built, I copied
> output/build/linux-4.19.16 to somewhere else, ran "make clean" and
> removed some .stamp files in order to get the buildroot make to
> rebuild the kernel.  I went into the binutils dir, reverted the patch
> you identified, ran make and copied ld/ld-new to
> output/host/bin/sh4-buildroot-linux-uclibc-ld (and ld.bfd).  Then ran
> make at the buildroot top level again to recompile the kernel using
> the new ld.  Why did I do things like that?  Because I like to control
> exactly what differs between two builds.

Ok.

>
>> Have you tried to run the system using Qemu and the command line provided
>> previously?
>
> Not until now.  I verified that kernels built with binutils-2.33.1
> with either the include/arch/vmlinux.lds.h fix or the mm/kmemleak.c
> fix fail.
>
> Digging into that, I copied the good linux-4.19.16/vmlinux and built a
> zImage from it.  That failed.  So there was another kernel bug.  I see
> this in an arch/sh/boot/compressed/vmlinux linker map file:
>
>  *(.rodata.*)
>  .rodata.str1.4
>                 0x000000008c8039a8      0x175 arch/sh/boot/compressed/misc.o
>  .rodata..compressed
>                 0x000000008c803b1d   0x2c4bd5 arch/sh/boot/compressed/piggy.o
>                 0x000000008c803b1d                input_len
>                 0x000000008c803b21                _binary_arch_sh_boot_compressed_vmlinux_bin_gz_start
>                 0x000000008c803b21                input_data
>                 0x000000008cac86ee                output_len
>                 0x000000008cac86f2                input_data_end
>                 0x000000008cac86f2                _binary_arch_sh_boot_compressed_vmlinux_bin_gz_end
>                 0x000000008cac86f4                . = ALIGN (0x4)
>
> So we have the compressed image sitting at an odd address.  It looks
> like the sh uncompressor can't handle that.
>
>
> Here's the fix then to cure these kernel bugs:
>
> --- ./include/asm-generic/vmlinux.lds.h~ 2019-01-17 07:34:38.000000000 +1030
> +++ ./include/asm-generic/vmlinux.lds.h 2019-12-09 11:36:05.778675948 +1030
> @@ -306,6 +306,7 @@
>   */
>  #ifndef RO_AFTER_INIT_DATA
>  #define RO_AFTER_INIT_DATA \
> + . = ALIGN(8); \
>   __start_ro_after_init = .; \
>   *(.data..ro_after_init) \
>   __end_ro_after_init = .;
>
> --- arch/sh/boot/compressed/vmlinux.scr~ 2019-01-17 07:34:38.000000000 +1030
> +++ arch/sh/boot/compressed/vmlinux.scr 2019-12-09 13:31:03.533135945 +1030
> @@ -1,6 +1,6 @@
>  SECTIONS
>  {
> -  .rodata..compressed : {
> +  .rodata..compressed : ALIGN(8) {
>   input_len = .;
>   LONG(input_data_end - input_data) input_data = .;
>   *(.data)
>

Thanks a lot for your time!
I tested your patch and the system boot successfully in Qemu.

I'll remove from Buildroot the patch in Binutils package and add theses two
patches for the sh4 kernel.

Can you send them upstream?
Thanks a lot.

Best regards,
Romain