GNU Binutils 2.41 release

GNU Binutils 2.41 release

[Nick Clifton]

Hi Everyone,

We are pleased to announce that version 2.41 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/

  Checksums:
  
a4c4bec052f7b8370024e60389e194377f3f48b56618418ea51067f67aaab30b  binutils-2.41.tar.bz2
2d046bc2ba09732a2da04f633aaab573e75c785c006dec1382d922532b60c1f7  binutils-2.41.tar.bz2.sig
48d00a8dc73aa7d2394a7dc069b96191d95e8de8f0da6dc91da5cce655c20e45  binutils-2.41.tar.gz
4b1de75756c497d913df84fdef8e7dfb977c77c8ad95ccfdaa2512bcc8983afe  binutils-2.41.tar.gz.sig
eab3444055882ed5eb04e2743d03f0c0e1bc950197a4ddd31898cd5a2843d065  binutils-2.41.tar.lz
2c13b50fc6e51d1044a6734e13e30c3cfdb02edd146552276e793b44a5e39c87  binutils-2.41.tar.lz.sig
ae9a5789e23459e59606e6714723f2d3ffc31c03174191ef0d015bdf06007450  binutils-2.41.tar.xz
6f72b25f95614ecbfd050ffdae628e00e90aec9073e30d8ab366e4fc9d1e9e2d  binutils-2.41.tar.xz.sig

As an experiment these tarballs were made with the new "-r <date>"
option supported by the src-release.sh script.  This attempts to make
reproducible tarballs by sorting the files and passing the
"--mtime=<date>" option to tar.  The date used for these tarballs was
obtained by running:

  git log -1 --format=%cd --date=format:%F bfd/version.m4

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

  In the assembler:
    * Add support for Intel FRED instructions.
    * Add support for Intel LKGS instructions.
    * Add support for Intel AMX-COMPLEX instructions.
    * Add SME2 support to the AArch64 port.
    * A new .insn directive is recognized by x86 gas.
    * Add support for LoongArch LSX instructions.
    * Add support for LoongArch LASX instructions.
    * Add support for LoongArch LVZ instructions.
    * Add support for LoongArch LBT instructions.
    * Initial LoongArch support for linker relaxation has been added.
    * Deprecate the LoongArch register aliases $v0, $v1, $x, $fv0 and $fv1.

  In the linker:
    * The linker now accepts a command line option of --remap-inputs
      <PATTERN>=<FILE> to relace any input file that matches <PATTERN> with
      <FILE>.  In addition the option --remap-inputs-file=<FILE> can be used to
      specify a file containing any number of these remapping directives.

    * The linker command line option --print-map-locals can be used to include
      local symbols in a linker map.  (ELF targets only).

    * For most ELF based targets, if the --enable-linker-version option is used
      then the version of the linker will be inserted as a string into the .comment
      section.

    * The linker script syntax has a new command for output sections: ASCIZ "string"
      This will insert a zero-terminated string at the current location.

    * Add command-line option, -z nosectionheader, to omit ELF section
      header.
  
  In the other binary tools:
    * The MIPS port now supports the Sony Interactive Entertainment Allegrex
      processor, used with the PlayStation Portable, which implements the MIPS
      II ISA along with a single-precision FPU and a few implementation-specific
      integer instructions.

    * Objdump's --private option can now be used on PE format files to display the
      fields in the file header and section headers.

    * New versioned release of libsframe: libsframe.so.1.  This release introduces
      versioned symbols with version node name LIBSFRAME_1.0.  This release also
      updates the ABI in an incompatible way: this includes removal of
      sframe_get_funcdesc_with_addr API, change in the behavior of
      sframe_fre_get_ra_offset and sframe_fre_get_fp_offset APIs.

    * SFrame Version 2 is now the default (and only) format version supported by
      gas, ld, readelf and objdump.
  
    * Add command-line option, --strip-section-headers, to objcopy and strip to
      remove ELF section header from ELF file.

    * The RISC-V port now supports the following new standard extensions:
      - Zicond (conditional zero instructions)
      - Zfa (additional floating-point instructions)
      - Zvbb, Zvbc, Zvkg, Zvkned, Zvknh[ab], Zvksed, Zvksh, Zvkn, Zvknc, Zvkng,
        Zvks, Zvksc, Zvkg, Zvkt (vector crypto instructions)

    * The RISC-V port now supports the following vendor-defined extensions:
       - XVentanaCondOps

    * The LoongArch port now supports the following extensions:
      - LSX (Loongson SIMD eXtension; 128-bit vectors)
      - LASX (Loongson Advanced SIMD eXtension; 256-bit vectors)
      - LVZ (Loongson Virtualization extension)
      - LBT (Loongson Binary Translation extension)

    * The LoongArch disassembly output received the following tweaks:
      - Colored output is now supported.
      - Some pseudo-instructions are now shown in place of the canonical forms,
        where semantics are equivalent. A disassembler option '-M no-aliases' is
        added to disable the new behavior.
      - Signed immediates are no longer printed with their hex representation.
      - Unrecognized instruction words are now shown with '.word'.

For more information see:

  https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gas/NEWS;;hb=refs/tags/binutils-2_41
  https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=ld/NEWS;hb=refs/tags/binutils-2_41
  https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/tags/binutils-2_41

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

Cheers
  Nick Clifton
  GNU Binutils Chief Maintainer
  

Re: GNU Binutils 2.41 release

[H.J. Lu]

On Sun, Jul 30, 2023 at 7:57 AM Nick Clifton via Binutils
<binutils@sourceware.org> wrote:
>
> Hi Everyone,
>
> We are pleased to announce that version 2.41 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/
>
>   Checksums:
>
> a4c4bec052f7b8370024e60389e194377f3f48b56618418ea51067f67aaab30b  binutils-2.41.tar.bz2
> 2d046bc2ba09732a2da04f633aaab573e75c785c006dec1382d922532b60c1f7  binutils-2.41.tar.bz2.sig
> 48d00a8dc73aa7d2394a7dc069b96191d95e8de8f0da6dc91da5cce655c20e45  binutils-2.41.tar.gz
> 4b1de75756c497d913df84fdef8e7dfb977c77c8ad95ccfdaa2512bcc8983afe  binutils-2.41.tar.gz.sig
> eab3444055882ed5eb04e2743d03f0c0e1bc950197a4ddd31898cd5a2843d065  binutils-2.41.tar.lz
> 2c13b50fc6e51d1044a6734e13e30c3cfdb02edd146552276e793b44a5e39c87  binutils-2.41.tar.lz.sig
> ae9a5789e23459e59606e6714723f2d3ffc31c03174191ef0d015bdf06007450  binutils-2.41.tar.xz
> 6f72b25f95614ecbfd050ffdae628e00e90aec9073e30d8ab366e4fc9d1e9e2d  binutils-2.41.tar.xz.sig
>
> As an experiment these tarballs were made with the new "-r <date>"
> option supported by the src-release.sh script.  This attempts to make
> reproducible tarballs by sorting the files and passing the
> "--mtime=<date>" option to tar.  The date used for these tarballs was
> obtained by running:
>
>   git log -1 --format=%cd --date=format:%F bfd/version.m4
>
> This release contains numerous bug fixes, and also the
> following new features:
>
>   In the assembler:
>     * Add support for Intel FRED instructions.
>     * Add support for Intel LKGS instructions.
>     * Add support for Intel AMX-COMPLEX instructions.
>     * Add SME2 support to the AArch64 port.
>     * A new .insn directive is recognized by x86 gas.
>     * Add support for LoongArch LSX instructions.
>     * Add support for LoongArch LASX instructions.
>     * Add support for LoongArch LVZ instructions.
>     * Add support for LoongArch LBT instructions.
>     * Initial LoongArch support for linker relaxation has been added.
>     * Deprecate the LoongArch register aliases $v0, $v1, $x, $fv0 and $fv1.
>
>   In the linker:
>     * The linker now accepts a command line option of --remap-inputs
>       <PATTERN>=<FILE> to relace any input file that matches <PATTERN> with
>       <FILE>.  In addition the option --remap-inputs-file=<FILE> can be used to
>       specify a file containing any number of these remapping directives.
>
>     * The linker command line option --print-map-locals can be used to include
>       local symbols in a linker map.  (ELF targets only).
>
>     * For most ELF based targets, if the --enable-linker-version option is used
>       then the version of the linker will be inserted as a string into the .comment
>       section.
>
>     * The linker script syntax has a new command for output sections: ASCIZ "string"
>       This will insert a zero-terminated string at the current location.
>
>     * Add command-line option, -z nosectionheader, to omit ELF section
>       header.
>
>   In the other binary tools:
>     * The MIPS port now supports the Sony Interactive Entertainment Allegrex
>       processor, used with the PlayStation Portable, which implements the MIPS
>       II ISA along with a single-precision FPU and a few implementation-specific
>       integer instructions.
>
>     * Objdump's --private option can now be used on PE format files to display the
>       fields in the file header and section headers.
>
>     * New versioned release of libsframe: libsframe.so.1.  This release introduces
>       versioned symbols with version node name LIBSFRAME_1.0.  This release also
>       updates the ABI in an incompatible way: this includes removal of
>       sframe_get_funcdesc_with_addr API, change in the behavior of
>       sframe_fre_get_ra_offset and sframe_fre_get_fp_offset APIs.
>
>     * SFrame Version 2 is now the default (and only) format version supported by
>       gas, ld, readelf and objdump.
>
>     * Add command-line option, --strip-section-headers, to objcopy and strip to
>       remove ELF section header from ELF file.
>
>     * The RISC-V port now supports the following new standard extensions:
>       - Zicond (conditional zero instructions)
>       - Zfa (additional floating-point instructions)
>       - Zvbb, Zvbc, Zvkg, Zvkned, Zvknh[ab], Zvksed, Zvksh, Zvkn, Zvknc, Zvkng,
>         Zvks, Zvksc, Zvkg, Zvkt (vector crypto instructions)
>
>     * The RISC-V port now supports the following vendor-defined extensions:
>        - XVentanaCondOps
>
>     * The LoongArch port now supports the following extensions:
>       - LSX (Loongson SIMD eXtension; 128-bit vectors)
>       - LASX (Loongson Advanced SIMD eXtension; 256-bit vectors)
>       - LVZ (Loongson Virtualization extension)
>       - LBT (Loongson Binary Translation extension)
>
>     * The LoongArch disassembly output received the following tweaks:
>       - Colored output is now supported.
>       - Some pseudo-instructions are now shown in place of the canonical forms,
>         where semantics are equivalent. A disassembler option '-M no-aliases' is
>         added to disable the new behavior.
>       - Signed immediates are no longer printed with their hex representation.
>       - Unrecognized instruction words are now shown with '.word'.
>
> For more information see:
>
>   https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gas/NEWS;;hb=refs/tags/binutils-2_41
>   https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=ld/NEWS;hb=refs/tags/binutils-2_41
>   https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/tags/binutils-2_41
>
> Our thanks go out to all of the binutils contributors, past and
> present, for helping to make this release possible.
>
> Cheers
>   Nick Clifton
>   GNU Binutils Chief Maintainer
>
>

The binutils-2_41 tag points to the wrong commit:

d3cc73ee4a (HEAD -> binutils-2_41-branch, origin/binutils-2_41-branch)
Updated Spanish translation for the gprof directory
ae85bd64903 Automatic date update in version.in
7872e3bdb0d Reset 2.41 branch back to development mode
2c73aeb8d2e (tag: binutils-2_41) The 2.41 release!

The binutils-2_41 tag has

m4_define([BFD_VERSION], [2.40.90])

-- 
H.J.

Re: GNU Binutils 2.41 release

[Nick Clifton]

Hi H.J.

> The binutils-2_41 tag points to the wrong commit:
> 
> d3cc73ee4a (HEAD -> binutils-2_41-branch, origin/binutils-2_41-branch)
> Updated Spanish translation for the gprof directory
> ae85bd64903 Automatic date update in version.in
> 7872e3bdb0d Reset 2.41 branch back to development mode
> 2c73aeb8d2e (tag: binutils-2_41) The 2.41 release!
> 
> The binutils-2_41 tag has
> 
> m4_define([BFD_VERSION], [2.40.90])

Darn.  I am not sure that I can do anything about this.

I must have missed running "git commit; git push" after changing
bfd/version.m4 to:

   m4_define([BFD_VERSION], [2.41])

And then making the source release tarballs.  So the tarballs are
OK but the tag points to an earlier version of the sources, just
before the release happened.  The problem is, there is no commit
that exactly corresponds to the released sources, so I cannot create
a new tag for the release point.

Any ideas ?

Cheers
   Nick

PS.  I have updated the README-how-to-make-a-release file to add
   a note to check for pending commits just before creating the source
   tarballs, so hopefully this issue will not happen again in the
   future.

Re: GNU Binutils 2.41 release

[Tsukasa OI]

On 2023/08/01 18:43, Nick Clifton via Binutils wrote:
> Hi H.J.
> 
>> The binutils-2_41 tag points to the wrong commit:
>>
>> d3cc73ee4a (HEAD -> binutils-2_41-branch, origin/binutils-2_41-branch)
>> Updated Spanish translation for the gprof directory
>> ae85bd64903 Automatic date update in version.in
>> 7872e3bdb0d Reset 2.41 branch back to development mode
>> 2c73aeb8d2e (tag: binutils-2_41) The 2.41 release!
>>
>> The binutils-2_41 tag has
>>
>> m4_define([BFD_VERSION], [2.40.90])
> 
> Darn.  I am not sure that I can do anything about this.
> 
> I must have missed running "git commit; git push" after changing
> bfd/version.m4 to:
> 
>   m4_define([BFD_VERSION], [2.41])
> 
> And then making the source release tarballs.  So the tarballs are
> OK but the tag points to an earlier version of the sources, just
> before the release happened.  The problem is, there is no commit
> that exactly corresponds to the released sources, so I cannot create
> a new tag for the release point.
> 
> Any ideas ?
> 
> Cheers
>   Nick

If we don't have to stick to the "binutils-2_41-branch", we could just
create real 2.41 commit, making the commit 2c73aeb8d2e0 ("The 2.41
release!") parent, then change the tag (the resulting commit will not be
a part of any branch).  That should create a duplicate diff to commit
7872e3bdb0de ("Reset 2.41 branch back to development mode") in the 2.41
branch but far better than "no real 2.41 on the repository".

Alternatively, we have an option to release 2.41.1 and yank the original
2.41(.0) (the SemVer way).  But that's probably overdoing.

Thanks,
Tsukasa

> 
> PS.  I have updated the README-how-to-make-a-release file to add
>   a note to check for pending commits just before creating the source
>   tarballs, so hopefully this issue will not happen again in the
>   future.
> 
> 

Re: GNU Binutils 2.41 release

[Nick Clifton]

Hi Guys,

On 7/31/23 18:25, H.J. Lu wrote:
> The binutils-2_41 tag points to the wrong commit:

Indeed it does.  In fact there was no commit that exactly corresponds to
the released sources.  A silly mistake on my part.

After some trial and error we now have a new branch (binutils-2_41-release-point)
and a new tag (binutils-2_41-official-release), that is a match for the released
sources.

There are no plans to ever make any changes to this branch - it is just there
so that we can have a tag that matches the release.

I will update the website to mention this problem, and I apologise
to anyone who has been caught out by the mis-tagging.

Cheers
   Nick

Re: GNU Binutils 2.41 release

[H.J. Lu]

On Fri, Aug 4, 2023 at 3:37 AM Nick Clifton <nickc@redhat.com> wrote:
>
> Hi Guys,
>
> On 7/31/23 18:25, H.J. Lu wrote:
> > The binutils-2_41 tag points to the wrong commit:
>
> Indeed it does.  In fact there was no commit that exactly corresponds to
> the released sources.  A silly mistake on my part.
>
> After some trial and error we now have a new branch (binutils-2_41-release-point)
> and a new tag (binutils-2_41-official-release), that is a match for the released
> sources.
>
> There are no plans to ever make any changes to this branch - it is just there
> so that we can have a tag that matches the release.
>
> I will update the website to mention this problem, and I apologise
> to anyone who has been caught out by the mis-tagging.
>

Thanks.


-- 
H.J.

Re: GNU Binutils 2.41 release

[ASSI]

Nick Clifton via Binutils writes:
> We are pleased to announce that version 2.41 of the GNU Binutils project
> sources have been released and are now available for download at:
[…]

I see massive performance degradation in ld on Cygwin when linking
libraries or executables with a large number of objects.

For example compiling protobuf-21.12:

binutils-2.39: 1420.820u 143.747s  3:20.37 780.8%      0+0k 0+0io 41531073pf+0w
binutils-2.40: 1429.088u 140.548s  3:18.48 790.8%      0+0k 0+0io 41615637pf+0w
binutils-2.41: 1496.555u 524.457s 10:07.31 332.7%      0+0k 0+0io 41570112pf+0w

The linking step alone:

binutils-2.39:   14.212u   2.614s  0:20.54 81.8%       0+0k 0+0io 1909884pf+0w
binutils-2.40:   13.371u   0.839s  0:20.46 69.4%       0+0k 0+0io 1910885pf+0w
binutils-2.41:   85.507u 373.960s  7:55.39 96.6%       0+0k 0+0io 1905021pf+0w

I have another much larger application where the linking went from
seconds to over an hour.

The fact that a lot of that extra time is spent in system might provide
a clue for finding the culprit.  BUt there's extra time in user as well
and it seems to scale superlinearly with the number of objects.  It's
possible that objdump performance has also suffered, I've not yet
checked this in detail.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: GNU Binutils 2.41 release

[Sam James]

ASSI <Stromeko@nexgo.de> writes:

> Nick Clifton via Binutils writes:
>> We are pleased to announce that version 2.41 of the GNU Binutils project
>> sources have been released and are now available for download at:
> […]
>
> I see massive performance degradation in ld on Cygwin when linking
> libraries or executables with a large number of objects.
>
> For example compiling protobuf-21.12:
>
> binutils-2.39: 1420.820u 143.747s  3:20.37 780.8%      0+0k 0+0io 41531073pf+0w
> binutils-2.40: 1429.088u 140.548s  3:18.48 790.8%      0+0k 0+0io 41615637pf+0w
> binutils-2.41: 1496.555u 524.457s 10:07.31 332.7%      0+0k 0+0io 41570112pf+0w
>
> The linking step alone:
>
> binutils-2.39:   14.212u   2.614s  0:20.54 81.8%       0+0k 0+0io 1909884pf+0w
> binutils-2.40:   13.371u   0.839s  0:20.46 69.4%       0+0k 0+0io 1910885pf+0w
> binutils-2.41:   85.507u 373.960s  7:55.39 96.6%       0+0k 0+0io 1905021pf+0w
>
> I have another much larger application where the linking went from
> seconds to over an hour.
>
> The fact that a lot of that extra time is spent in system might provide
> a clue for finding the culprit.  BUt there's extra time in user as well
> and it seems to scale superlinearly with the number of objects.  It's
> possible that objdump performance has also suffered, I've not yet
> checked this in detail.
>

Please file a bug with the details so we can discuss it there and
collect some reproducers.

>
> Regards,
> Achim.

Re: GNU Binutils 2.41 release

[ASSI]

On Samstag, 5. August 2023 02:38:06 CEST Sam James wrote:
> Please file a bug with the details so we can discuss it there and
> collect some reproducers.


https://sourceware.org/bugzilla/show_bug.cgi?id=30724
https://sourceware.org/bugzilla/show_bug.cgi?id=30725


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: GNU Binutils 2.41 release

[Tsukasa OI]

On 2023/08/05 9:38, Sam James via Binutils wrote:
> 
> ASSI <Stromeko@nexgo.de> writes:
> 
>> Nick Clifton via Binutils writes:
>>> We are pleased to announce that version 2.41 of the GNU Binutils project
>>> sources have been released and are now available for download at:
>> […]
>>
>> I see massive performance degradation in ld on Cygwin when linking
>> libraries or executables with a large number of objects.
>>
>> For example compiling protobuf-21.12:
>>
>> binutils-2.39: 1420.820u 143.747s  3:20.37 780.8%      0+0k 0+0io 41531073pf+0w
>> binutils-2.40: 1429.088u 140.548s  3:18.48 790.8%      0+0k 0+0io 41615637pf+0w
>> binutils-2.41: 1496.555u 524.457s 10:07.31 332.7%      0+0k 0+0io 41570112pf+0w
>>
>> The linking step alone:
>>
>> binutils-2.39:   14.212u   2.614s  0:20.54 81.8%       0+0k 0+0io 1909884pf+0w
>> binutils-2.40:   13.371u   0.839s  0:20.46 69.4%       0+0k 0+0io 1910885pf+0w
>> binutils-2.41:   85.507u 373.960s  7:55.39 96.6%       0+0k 0+0io 1905021pf+0w
>>
>> I have another much larger application where the linking went from
>> seconds to over an hour.
>>
>> The fact that a lot of that extra time is spent in system might provide
>> a clue for finding the culprit.  BUt there's extra time in user as well
>> and it seems to scale superlinearly with the number of objects.  It's
>> possible that objdump performance has also suffered, I've not yet
>> checked this in detail.
>>
> 
> Please file a bug with the details so we can discuss it there and
> collect some reproducers.
> 
>>
>> Regards,
>> Achim.
> 

As well as the issue reported by ASSI, I found similar report (possibly
a linker performance regression with Cygwin) in X (formerly Twitter).  I
asked him to detail the issue and he kindly provided me a report (though
in Japanese).  At least I'll try some gprof-based profiling.

<https://fd0.hatenablog.jp/entry/2023/08/05/220135>

Tsukasa