Getting ready for the 2.39 branch/release

Getting ready for the 2.39 branch/release

[Nick Clifton]

Hi Guys,

   It is time to think about the next GNU Binutils release.

   Ideally I would like to make the release at the end of July
   which will be 6 months on from the 2.38 release.  Unfortunately
   I am on vacation for two weeks in the middle of July (11-22) so
   either:

   1. Someone else volunteers to make the 2.39 release.

   2. I create the branch early (eg Saturday June 25) but then
      release late (eg Saturday July 30) and the global maintainers
      get to approve patches for the branch.

      This does not give much time for people to get new features
      into the sources before the branch is cut...

   3. I create the branch in a couple of week's time (eg Fri Jul 8)
      and then release early in August (eg Sat Aug 6) and again I
      ask the global maintainers for help in approving patches for
      the branch.

   Thoughts ?

Cheers
   Nick

Re: Getting ready for the 2.39 branch/release

[Jan Beulich]

On 21.06.2022 13:09, Nick Clifton via Binutils wrote:
> Hi Guys,
> 
>    It is time to think about the next GNU Binutils release.
> 
>    Ideally I would like to make the release at the end of July
>    which will be 6 months on from the 2.38 release.  Unfortunately
>    I am on vacation for two weeks in the middle of July (11-22) so
>    either:
> 
>    1. Someone else volunteers to make the 2.39 release.
> 
>    2. I create the branch early (eg Saturday June 25) but then
>       release late (eg Saturday July 30) and the global maintainers
>       get to approve patches for the branch.
> 
>       This does not give much time for people to get new features
>       into the sources before the branch is cut...
> 
>    3. I create the branch in a couple of week's time (eg Fri Jul 8)
>       and then release early in August (eg Sat Aug 6) and again I
>       ask the global maintainers for help in approving patches for
>       the branch.

Fwiw my preference would be 3.

Jan

Re: Getting ready for the 2.39 branch/release

[Matthias Klose]

On 21.06.22 13:09, Nick Clifton via Binutils wrote:
> Hi Guys,
> 
>    It is time to think about the next GNU Binutils release.
> 
>    Ideally I would like to make the release at the end of July
>    which will be 6 months on from the 2.38 release.  Unfortunately
>    I am on vacation for two weeks in the middle of July (11-22) so
>    either:
> 
>    1. Someone else volunteers to make the 2.39 release.
> 
>    2. I create the branch early (eg Saturday June 25) but then
>       release late (eg Saturday July 30) and the global maintainers
>       get to approve patches for the branch.
> 
>       This does not give much time for people to get new features
>       into the sources before the branch is cut...
> 
>    3. I create the branch in a couple of week's time (eg Fri Jul 8)
>       and then release early in August (eg Sat Aug 6) and again I
>       ask the global maintainers for help in approving patches for
>       the branch.
> 
>    Thoughts ?

Debian and Ubuntu are using the current trunk for the releases in development. 
There's currently one issue that I'm aware of:

   https://bugs.debian.org/1013244

just asked the Debian mips porters about it.

As I understand, some minor gprofng configuration issues are being worked on.

Matthias

Re: Getting ready for the 2.39 branch/release

[Vladimir Mezentsev]

On 6/22/22 12:35, Matthias Klose wrote:
> On 21.06.22 13:09, Nick Clifton via Binutils wrote:
>> Hi Guys,
>>
>>    It is time to think about the next GNU Binutils release.
>>
>>    Ideally I would like to make the release at the end of July
>>    which will be 6 months on from the 2.38 release. Unfortunately
>>    I am on vacation for two weeks in the middle of July (11-22) so
>>    either:
>>
>>    1. Someone else volunteers to make the 2.39 release.
>>
>>    2. I create the branch early (eg Saturday June 25) but then
>>       release late (eg Saturday July 30) and the global maintainers
>>       get to approve patches for the branch.
>>
>>       This does not give much time for people to get new features
>>       into the sources before the branch is cut...
>>
>>    3. I create the branch in a couple of week's time (eg Fri Jul 8)
>>       and then release early in August (eg Sat Aug 6) and again I
>>       ask the global maintainers for help in approving patches for
>>       the branch.
>>
>>    Thoughts ?
>
> Debian and Ubuntu are using the current trunk for the releases in 
> development. There's currently one issue that I'm aware of:
>
>   https://bugs.debian.org/1013244
>
> just asked the Debian mips porters about it.
>
> As I understand, some minor gprofng configuration issues are being 
> worked on.

  gprofng has these bugs:

ID    Product    Comp    Assignee▲ Status▲    Resolution    Summary
29131    binutils    gprofng    vladimir.mezentsev@oracle.com UNCO    No 
rule to make target 'gprofng.1', needed by 'all-am'. Stop. For arm
29191    binutils    gprofng    vladimir.mezentsev@oracle.com ASSI    
gprofng ignores --sysconfdir configuration option
29116    binutils    gprofng    vladimir.mezentsev@oracle.com ASSI    
gprofng fails to build on i686-linux-gnu, aarch64-linux-gnu

I plan to fix 29191 soon.
I cannot reproduce 29131.

I made a partial fix for 29116. I hope the issue is fixed for the Debian 
build.
But I can reproduce a similar issue if I configure my build with --host= 
and  -m32 options.
I plan to make an additional fix for 29116 soon.

-Vladimir

>
> Matthias

Re: Getting ready for the 2.39 branch/release

[Matthias Klose]

On 23.06.22 01:00, Vladimir Mezentsev via Binutils wrote:
> 
> 
> On 6/22/22 12:35, Matthias Klose wrote:
>> On 21.06.22 13:09, Nick Clifton via Binutils wrote:
>>> Hi Guys,
>>>
>>>    It is time to think about the next GNU Binutils release.
>>>
>>>    Ideally I would like to make the release at the end of July
>>>    which will be 6 months on from the 2.38 release. Unfortunately
>>>    I am on vacation for two weeks in the middle of July (11-22) so
>>>    either:
>>>
>>>    1. Someone else volunteers to make the 2.39 release.
>>>
>>>    2. I create the branch early (eg Saturday June 25) but then
>>>       release late (eg Saturday July 30) and the global maintainers
>>>       get to approve patches for the branch.
>>>
>>>       This does not give much time for people to get new features
>>>       into the sources before the branch is cut...
>>>
>>>    3. I create the branch in a couple of week's time (eg Fri Jul 8)
>>>       and then release early in August (eg Sat Aug 6) and again I
>>>       ask the global maintainers for help in approving patches for
>>>       the branch.
>>>
>>>    Thoughts ?
>>
>> Debian and Ubuntu are using the current trunk for the releases in development. 
>> There's currently one issue that I'm aware of:
>>
>>   https://bugs.debian.org/1013244
>>
>> just asked the Debian mips porters about it.
>>
>> As I understand, some minor gprofng configuration issues are being worked on.
> 
>   gprofng has these bugs:
> 
> ID    Product    Comp    Assignee▲ Status▲    Resolution    Summary
> 29131    binutils    gprofng    vladimir.mezentsev@oracle.com UNCO    No rule to 
> make target 'gprofng.1', needed by 'all-am'. Stop. For arm
> 
> I cannot reproduce 29131.

I added some information to the bug report. This is only seen when cross 
building.  Cross building from a git snapshot doesn't have the generated man 
pages checked in, but man_MANS has them added unconditionally. Maybe make the 
definition of man_MANS conditional on BUILD_MAN as well?

That should not be an issue for releases, because the generated man pages are 
included in the release tarball (maybe Nick needs to update the release script 
for the newly added man pages?).

Matthias

Re: Getting ready for the 2.39 branch/release

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

Hi Matthias,

> Debian and Ubuntu are using the current trunk for the releases in development. There's currently one issue that I'm aware of:
> 
>    https://bugs.debian.org/1013244

Is there a corresponding binutils PR for this ?

Would the attached patch solve the problem ?

If the need for an executable stack is restricted to the hard-float ABI,
is there a way to determine this from the target configuration triplet ?

Is there an explanation somewhere of why the hard-float ABI needs an
executable stack - and possibly how this need might be removed ?

Cheers
   Nick

[-- Attachment #2: p.patch --]
[-- Type: text/x-patch, Size: 1712 bytes --]

diff --git a/ld/configure b/ld/configure
index 95c21406b41..14311847b57 100755
--- a/ld/configure
+++ b/ld/configure
@@ -15465,6 +15465,8 @@ case "${target}" in
   # The HPPA port needs to support older kernels that use executable stacks
   # for signals and syscalls.
   hppa*-*-*) ac_default_ld_warn_execstack=0 ;;
+  # Similarly for MIPS targets.
+  mips*-*-*) ac_default_ld_warn_execstack=0 ;;
   *) ac_default_ld_warn_execstack=2 ;;
   esac
 # Check whether --enable-warn-execstack was given.
@@ -17281,6 +17283,8 @@ if test "${ac_default_ld_warn_rwx_segments}" = unset; then
   # The HPPA's PLT section uses a constructed trampoline, hence it needs to
   # have a RWX segment.
   hppa*-*-*) ac_default_ld_warn_rwx_segments=0 ;;
+  # Similarly for MIPS targets.
+  mips*-*-*) ac_default_ld_warn_execstack=0 ;;
   *) ac_default_ld_warn_rwx_segments=1 ;;
   esac
 fi
diff --git a/ld/configure.ac b/ld/configure.ac
index d587c46cc51..fc8b94c9290 100644
--- a/ld/configure.ac
+++ b/ld/configure.ac
@@ -210,6 +210,8 @@ esac])
   # The HPPA port needs to support older kernels that use executable stacks
   # for signals and syscalls.
   hppa*-*-*) ac_default_ld_warn_execstack=0 ;;
+  # Similarly for MIPS targets.
+  mips*-*-*) ac_default_ld_warn_execstack=0 ;;
   *) ac_default_ld_warn_execstack=2 ;;
   esac]
 AC_ARG_ENABLE(warn-execstack,
@@ -573,6 +575,8 @@ if test "${ac_default_ld_warn_rwx_segments}" = unset; then
   # The HPPA's PLT section uses a constructed trampoline, hence it needs to
   # have a RWX segment.
   hppa*-*-*) ac_default_ld_warn_rwx_segments=0 ;;
+  # Similarly for MIPS targets.
+  mips*-*-*) ac_default_ld_warn_execstack=0 ;;
   *) ac_default_ld_warn_rwx_segments=1 ;;
   esac]
 fi

Re: Getting ready for the 2.39 branch/release

[Matthias Klose]

On 23.06.22 12:07, Nick Clifton wrote:
> Hi Matthias,
> 
>> Debian and Ubuntu are using the current trunk for the releases in development. 
>> There's currently one issue that I'm aware of:
>>
>>    https://bugs.debian.org/1013244
> 
> Is there a corresponding binutils PR for this ?

No, not yet.

> Would the attached patch solve the problem ?

did you want to set ac_default_ld_warn_rwx_segments in the second chunk?

> If the need for an executable stack is restricted to the hard-float ABI,
> is there a way to determine this from the target configuration triplet ?
> 
> Is there an explanation somewhere of why the hard-float ABI needs an
> executable stack - and possibly how this need might be removed ?

I had asked a mips porter, no reply yet.

Matthias

Re: Getting ready for the 2.39 branch/release

[Nick Clifton]

Hi Matthias,

> did you want to set ac_default_ld_warn_rwx_segments in the second chunk?

Oops - yes, sorry about that!

Cheers
   Nick

Re: Getting ready for the 2.39 branch/release

[Hans-Peter Nilsson]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

On Thu, 23 Jun 2022, Nick Clifton via Binutils wrote:

> Hi Matthias,
>
> > Debian and Ubuntu are using the current trunk for the releases in
> > development. There's currently one issue that I'm aware of:
> >
> >  ? https://bugs.debian.org/1013244
>
> Is there a corresponding binutils PR for this ?
>
> Would the attached patch solve the problem ?

I would again suggest to not do this in ld/configure.ac but
instead in ld/configure.tgt as in 5d02a15.

Not needing to find the right autotools is a good reason,
methinks.

brgds, H-P

[-- Attachment #2: Type: text/x-patch, Size: 1712 bytes --]

diff --git a/ld/configure b/ld/configure
index 95c21406b41..14311847b57 100755
--- a/ld/configure
+++ b/ld/configure
@@ -15465,6 +15465,8 @@ case "${target}" in
   # The HPPA port needs to support older kernels that use executable stacks
   # for signals and syscalls.
   hppa*-*-*) ac_default_ld_warn_execstack=0 ;;
+  # Similarly for MIPS targets.
+  mips*-*-*) ac_default_ld_warn_execstack=0 ;;
   *) ac_default_ld_warn_execstack=2 ;;
   esac
 # Check whether --enable-warn-execstack was given.
@@ -17281,6 +17283,8 @@ if test "${ac_default_ld_warn_rwx_segments}" = unset; then
   # The HPPA's PLT section uses a constructed trampoline, hence it needs to
   # have a RWX segment.
   hppa*-*-*) ac_default_ld_warn_rwx_segments=0 ;;
+  # Similarly for MIPS targets.
+  mips*-*-*) ac_default_ld_warn_execstack=0 ;;
   *) ac_default_ld_warn_rwx_segments=1 ;;
   esac
 fi
diff --git a/ld/configure.ac b/ld/configure.ac
index d587c46cc51..fc8b94c9290 100644
--- a/ld/configure.ac
+++ b/ld/configure.ac
@@ -210,6 +210,8 @@ esac])
   # The HPPA port needs to support older kernels that use executable stacks
   # for signals and syscalls.
   hppa*-*-*) ac_default_ld_warn_execstack=0 ;;
+  # Similarly for MIPS targets.
+  mips*-*-*) ac_default_ld_warn_execstack=0 ;;
   *) ac_default_ld_warn_execstack=2 ;;
   esac]
 AC_ARG_ENABLE(warn-execstack,
@@ -573,6 +575,8 @@ if test "${ac_default_ld_warn_rwx_segments}" = unset; then
   # The HPPA's PLT section uses a constructed trampoline, hence it needs to
   # have a RWX segment.
   hppa*-*-*) ac_default_ld_warn_rwx_segments=0 ;;
+  # Similarly for MIPS targets.
+  mips*-*-*) ac_default_ld_warn_execstack=0 ;;
   *) ac_default_ld_warn_rwx_segments=1 ;;
   esac]
 fi

Re: Getting ready for the 2.39 branch/release

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

Hi Hans-Peter,

> I would again suggest to not do this in ld/configure.ac but
> instead in ld/configure.tgt as in 5d02a15.

Sorry for missing that suggestion.  You are correct - it is a better
method.

Dave, Matthias - any objections to the attached patch ?

It moves the current HPPA special case code from configure.ac into
configure.tgt, adds an exception for MIPS targets and moves all of
this (including the CRIS case) to the start of configure.tgt where
it will be easy to add support for more targets should it prove
necessary.

Cheers
   Nick


[-- Attachment #2: p.patch --]
[-- Type: text/x-patch, Size: 3235 bytes --]

diff --git a/ld/configure.ac b/ld/configure.ac
index d587c46cc51..a54a2801889 100644
--- a/ld/configure.ac
+++ b/ld/configure.ac
@@ -206,12 +206,7 @@ esac])
 
 # By default warn when an executable stack is created due to object files
 # requesting such, not when the user specifies -z execstack.
-[case "${target}" in
-  # The HPPA port needs to support older kernels that use executable stacks
-  # for signals and syscalls.
-  hppa*-*-*) ac_default_ld_warn_execstack=0 ;;
-  *) ac_default_ld_warn_execstack=2 ;;
-  esac]
+ac_default_ld_warn_execstack=2
 AC_ARG_ENABLE(warn-execstack,
 	      AS_HELP_STRING([--enable-warn-execstack],
 	      [enable warnings when creating an executable stack]),
@@ -569,12 +564,7 @@ AC_DEFINE_UNQUOTED(DEFAULT_LD_WARN_EXECSTACK,
   [Define to 1 if you want to enable --warn-execstack in ELF linker by default.])
 
 if test "${ac_default_ld_warn_rwx_segments}" = unset; then
-  [case "${target}" in
-  # The HPPA's PLT section uses a constructed trampoline, hence it needs to
-  # have a RWX segment.
-  hppa*-*-*) ac_default_ld_warn_rwx_segments=0 ;;
-  *) ac_default_ld_warn_rwx_segments=1 ;;
-  esac]
+  ac_default_ld_warn_rwx_segments=1 ;;
 fi
 AC_DEFINE_UNQUOTED(DEFAULT_LD_WARN_RWX_SEGMENTS,
   $ac_default_ld_warn_rwx_segments,
diff --git a/ld/configure.tgt b/ld/configure.tgt
index 66b81550458..e8d1db9f8c1 100644
--- a/ld/configure.tgt
+++ b/ld/configure.tgt
@@ -40,6 +40,42 @@ targ_extra_ofiles="ldelf.o ldelfgen.o"
 targ64_extra_emuls=
 targ64_extra_libpath=
 
+# By default the linker will generate warnings if it is creating an
+# executable stack or a segment with all three of read, write and
+# execute permissions.  These settings are not appropriate for all
+# targets however, so we can change them here:
+
+if test "${ac_default_ld_warn_rwx_segments}" = unset; then
+  case "${targ}" in
+      # The CRIS default linker script yields just one segment
+      # as intended, so a rwx segment warning is not helpful.
+      # The HPPA's PLT section uses a constructed trampoline
+      # hence it needs to have a RWX segment.
+      # Many MIPS targets use executable segments.
+    cris-*-* | crisv32-*-* | \
+    hppa*-*-* | \
+    mips*-*-*)
+      ac_default_ld_warn_rwx_segments=0
+      ;;
+    *)
+      ;;
+  esac
+fi
+
+if test "${ac_default_ld_warn_execstack}" = 2; then
+  case "${targ}" in
+      # The HPPA port needs to support older kernels that
+      # use executable stacks for signals and syscalls.
+      # Many MIPS targets use executable stacks.
+    hppa*-*-* | \
+    mips*-*-*)
+      ac_default_ld_warn_execstack=0
+      ;;
+    *)
+      ;;
+  esac
+fi
+
 # Please try to keep this table more or less in alphabetic order - it
 # makes it much easier to lookup a specific archictecture.
 case "${targ}" in
@@ -235,11 +271,6 @@ cris-*-linux-* | crisv32-*-linux-*)
 cris-*-* | crisv32-*-*)	targ_emul=criself
 			targ_extra_emuls="crisaout crislinux"
 			targ_extra_libpath=$targ_extra_emuls
-			# The default linker script yields just one segment
-			# as intended, and then a warning is not helpful.
-			if test "${ac_default_ld_warn_rwx_segments}" = unset; then
-			  ac_default_ld_warn_rwx_segments=0
-			fi
 			;;
 crx-*-elf*)		targ_emul=elf32crx
 			;;