* Getting ready for the 2.39 branch/release
@ 2022-06-21 11:09 Nick Clifton
2022-06-22 6:36 ` Jan Beulich
2022-06-22 19:35 ` Matthias Klose
0 siblings, 2 replies; 10+ messages in thread
From: Nick Clifton @ 2022-06-21 11:09 UTC (permalink / raw)
To: Binutils
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting ready for the 2.39 branch/release
2022-06-21 11:09 Getting ready for the 2.39 branch/release Nick Clifton
@ 2022-06-22 6:36 ` Jan Beulich
2022-06-22 19:35 ` Matthias Klose
1 sibling, 0 replies; 10+ messages in thread
From: Jan Beulich @ 2022-06-22 6:36 UTC (permalink / raw)
To: Nick Clifton; +Cc: Binutils
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting ready for the 2.39 branch/release
2022-06-21 11:09 Getting ready for the 2.39 branch/release Nick Clifton
2022-06-22 6:36 ` Jan Beulich
@ 2022-06-22 19:35 ` Matthias Klose
2022-06-22 23:00 ` Vladimir Mezentsev
2022-06-23 10:07 ` Nick Clifton
1 sibling, 2 replies; 10+ messages in thread
From: Matthias Klose @ 2022-06-22 19:35 UTC (permalink / raw)
To: binutils, YunQiang Su
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting ready for the 2.39 branch/release
2022-06-22 19:35 ` Matthias Klose
@ 2022-06-22 23:00 ` Vladimir Mezentsev
2022-06-23 12:50 ` Matthias Klose
2022-06-23 10:07 ` Nick Clifton
1 sibling, 1 reply; 10+ messages in thread
From: Vladimir Mezentsev @ 2022-06-22 23:00 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting ready for the 2.39 branch/release
2022-06-22 19:35 ` Matthias Klose
2022-06-22 23:00 ` Vladimir Mezentsev
@ 2022-06-23 10:07 ` Nick Clifton
2022-06-23 13:07 ` Matthias Klose
2022-06-23 23:02 ` Hans-Peter Nilsson
1 sibling, 2 replies; 10+ messages in thread
From: Nick Clifton @ 2022-06-23 10:07 UTC (permalink / raw)
To: Matthias Klose, binutils, YunQiang Su
[-- 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting ready for the 2.39 branch/release
2022-06-22 23:00 ` Vladimir Mezentsev
@ 2022-06-23 12:50 ` Matthias Klose
0 siblings, 0 replies; 10+ messages in thread
From: Matthias Klose @ 2022-06-23 12:50 UTC (permalink / raw)
To: Vladimir Mezentsev, binutils
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting ready for the 2.39 branch/release
2022-06-23 10:07 ` Nick Clifton
@ 2022-06-23 13:07 ` Matthias Klose
2022-06-23 15:43 ` Nick Clifton
2022-06-23 23:02 ` Hans-Peter Nilsson
1 sibling, 1 reply; 10+ messages in thread
From: Matthias Klose @ 2022-06-23 13:07 UTC (permalink / raw)
To: Nick Clifton, binutils, YunQiang Su; +Cc: debian-mips
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting ready for the 2.39 branch/release
2022-06-23 13:07 ` Matthias Klose
@ 2022-06-23 15:43 ` Nick Clifton
0 siblings, 0 replies; 10+ messages in thread
From: Nick Clifton @ 2022-06-23 15:43 UTC (permalink / raw)
To: Matthias Klose, binutils, YunQiang Su; +Cc: debian-mips
Hi Matthias,
> did you want to set ac_default_ld_warn_rwx_segments in the second chunk?
Oops - yes, sorry about that!
Cheers
Nick
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting ready for the 2.39 branch/release
2022-06-23 10:07 ` Nick Clifton
2022-06-23 13:07 ` Matthias Klose
@ 2022-06-23 23:02 ` Hans-Peter Nilsson
2022-06-24 10:01 ` Nick Clifton
1 sibling, 1 reply; 10+ messages in thread
From: Hans-Peter Nilsson @ 2022-06-23 23:02 UTC (permalink / raw)
To: Nick Clifton; +Cc: Matthias Klose, binutils, YunQiang Su
[-- 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Getting ready for the 2.39 branch/release
2022-06-23 23:02 ` Hans-Peter Nilsson
@ 2022-06-24 10:01 ` Nick Clifton
0 siblings, 0 replies; 10+ messages in thread
From: Nick Clifton @ 2022-06-24 10:01 UTC (permalink / raw)
To: Hans-Peter Nilsson, Matthias Klose, danglin; +Cc: binutils, YunQiang Su
[-- 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
;;
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-06-24 10:01 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-21 11:09 Getting ready for the 2.39 branch/release Nick Clifton
2022-06-22 6:36 ` Jan Beulich
2022-06-22 19:35 ` Matthias Klose
2022-06-22 23:00 ` Vladimir Mezentsev
2022-06-23 12:50 ` Matthias Klose
2022-06-23 10:07 ` Nick Clifton
2022-06-23 13:07 ` Matthias Klose
2022-06-23 15:43 ` Nick Clifton
2022-06-23 23:02 ` Hans-Peter Nilsson
2022-06-24 10:01 ` Nick Clifton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).