[PATCH] Disable year 2038 support on 32-bit hosts by default

[PATCH] Disable year 2038 support on 32-bit hosts by default

[Luis Machado]

With a recent import of gnulib, code has been pulled that tests and enables
64-bit time_t by default on 32-bit hosts that support it.

Although gdb can use the gnulib support, bfd doesn't use gnulib and currently
doesn't do these checks.

As a consequence, if we have a 32-bit host that supports 64-bit time_t, we'll
have a mismatch between gdb's notion of time_t and bfd's notion of time_t.

This will lead to mismatches in the struct stat size, leading to memory
corruption and crashes.

This patch disables the year 2038 check for now, which makes things work
reliably again.

I'd consider this a temporary fix until we have proper bfd checks for the year
2038, if it makes sense.  64-bit hosts seems to be more common these days, so
I'm not sure how important it is to have this support enabled and how soon
we want to enable it.

Thoughts?
---
 configure    | 22 ++++++++++++++++++++++
 configure.ac | 18 ++++++++++++++++++
 2 files changed, 40 insertions(+)

diff --git a/configure b/configure
index be433ef6d5d..16139e3bfa3 100755
--- a/configure
+++ b/configure
@@ -790,6 +790,7 @@ enable_gold
 enable_ld
 enable_gprofng
 enable_compressed_debug_sections
+enable_year2038
 enable_libquadmath
 enable_libquadmath_support
 enable_libada
@@ -1520,6 +1521,7 @@ Optional Features:
   --enable-compressed-debug-sections={all,gas,gold,ld,none}
                           Enable compressed debug sections for gas, gold or ld
                           by default
+  --enable-year2038       enable support for timestamps past the year 2038
   --disable-libquadmath   do not build libquadmath directory
   --disable-libquadmath-support
                           disable libquadmath support for Fortran
@@ -3127,6 +3129,20 @@ case "${host}" in
     ;;
 esac
 
+# Default to --disable-year2038 until we can handle differences between
+# projects that use gnulib (which understands year 2038) and projects that
+# do not (like BFD).
+# Check whether --enable-year2038 was given.
+if test "${enable_year2038+set}" = set; then :
+  enableval=$enable_year2038; ENABLE_YEAR2038=$enableval
+else
+  ENABLE_YEAR2038=no
+fi
+
+enable_year2038=
+if test "${ENABLE_YEAR2038}" = "no" ; then
+  enable_year2038=no
+fi
 
 # Check whether --enable-libquadmath was given.
 if test "${enable_libquadmath+set}" = set; then :
@@ -7836,9 +7852,15 @@ if test "$silent" = yes; then
   baseargs="$baseargs --silent"
   tbaseargs="$tbaseargs --silent"
 fi
+
 baseargs="$baseargs --disable-option-checking"
 tbaseargs="$tbaseargs --disable-option-checking"
 
+if test "$enable_year2038" = no; then
+  baseargs="$baseargs --disable-year2038"
+  tbaseargs="$tbaseargs --disable-year2038"
+fi
+
 # Record and document user additions to sub configure arguments.
 
 
diff --git a/configure.ac b/configure.ac
index 1651cbf3b02..a5555a9c91b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -440,6 +440,18 @@ case "${host}" in
     ;;
 esac
 
+# Default to --disable-year2038 until we can handle differences between
+# projects that use gnulib (which understands year 2038) and projects that
+# do not (like BFD).
+AC_ARG_ENABLE(year2038,
+AS_HELP_STRING([--enable-year2038],
+  [enable support for timestamps past the year 2038]),
+ENABLE_YEAR2038=$enableval,
+ENABLE_YEAR2038=no)
+enable_year2038=
+if test "${ENABLE_YEAR2038}" = "no" ; then
+  enable_year2038=no
+fi
 
 AC_ARG_ENABLE(libquadmath,
 AS_HELP_STRING([--disable-libquadmath],
@@ -3139,9 +3151,15 @@ if test "$silent" = yes; then
   baseargs="$baseargs --silent"
   tbaseargs="$tbaseargs --silent"
 fi
+
 baseargs="$baseargs --disable-option-checking"
 tbaseargs="$tbaseargs --disable-option-checking"
 
+if test "$enable_year2038" = no; then
+  baseargs="$baseargs --disable-year2038"
+  tbaseargs="$tbaseargs --disable-year2038"
+fi
+
 # Record and document user additions to sub configure arguments.
 AC_ARG_VAR([build_configargs],
 	   [additional configure arguments for build directories])
-- 
2.25.1

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Simon Marchi]

On 2022-08-01 03:51, Luis Machado via Gdb-patches wrote:
> With a recent import of gnulib, code has been pulled that tests and enables
> 64-bit time_t by default on 32-bit hosts that support it.
> 
> Although gdb can use the gnulib support, bfd doesn't use gnulib and currently
> doesn't do these checks.
> 
> As a consequence, if we have a 32-bit host that supports 64-bit time_t, we'll
> have a mismatch between gdb's notion of time_t and bfd's notion of time_t.
> 
> This will lead to mismatches in the struct stat size, leading to memory
> corruption and crashes.
> 
> This patch disables the year 2038 check for now, which makes things work
> reliably again.
> 
> I'd consider this a temporary fix until we have proper bfd checks for the year
> 2038, if it makes sense.  64-bit hosts seems to be more common these days, so
> I'm not sure how important it is to have this support enabled and how soon
> we want to enable it.

I don't understand: why offer a --enable-year2038 switch if using it
would produce a broken build?

Simon

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Luis Machado]

On 8/1/22 15:08, Simon Marchi wrote:
> 
> 
> On 2022-08-01 03:51, Luis Machado via Gdb-patches wrote:
>> With a recent import of gnulib, code has been pulled that tests and enables
>> 64-bit time_t by default on 32-bit hosts that support it.
>>
>> Although gdb can use the gnulib support, bfd doesn't use gnulib and currently
>> doesn't do these checks.
>>
>> As a consequence, if we have a 32-bit host that supports 64-bit time_t, we'll
>> have a mismatch between gdb's notion of time_t and bfd's notion of time_t.
>>
>> This will lead to mismatches in the struct stat size, leading to memory
>> corruption and crashes.
>>
>> This patch disables the year 2038 check for now, which makes things work
>> reliably again.
>>
>> I'd consider this a temporary fix until we have proper bfd checks for the year
>> 2038, if it makes sense.  64-bit hosts seems to be more common these days, so
>> I'm not sure how important it is to have this support enabled and how soon
>> we want to enable it.
> 
> I don't understand: why offer a --enable-year2038 switch if using it
> would produce a broken build?

That switch is already offered by gnulib since the recent import, and it is on by default. So in practice it produces a broken build for 32-bit hosts
running a distro that understands 64-bit time_t. It's been broken for a while now.

What I'm suggesting is having a temporary fix so default builds aren't silently broken due to a mismatch in stat size between GDB and BFD.

It isn't clear to me if we really want to switch to 64-bit time_t for 32-bit hosts at this point. There is potential for more breakage.

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Simon Marchi]

On 2022-08-01 10:17, Luis Machado wrote:
> On 8/1/22 15:08, Simon Marchi wrote:
>>
>>
>> On 2022-08-01 03:51, Luis Machado via Gdb-patches wrote:
>>> With a recent import of gnulib, code has been pulled that tests and enables
>>> 64-bit time_t by default on 32-bit hosts that support it.
>>>
>>> Although gdb can use the gnulib support, bfd doesn't use gnulib and currently
>>> doesn't do these checks.
>>>
>>> As a consequence, if we have a 32-bit host that supports 64-bit time_t, we'll
>>> have a mismatch between gdb's notion of time_t and bfd's notion of time_t.
>>>
>>> This will lead to mismatches in the struct stat size, leading to memory
>>> corruption and crashes.
>>>
>>> This patch disables the year 2038 check for now, which makes things work
>>> reliably again.
>>>
>>> I'd consider this a temporary fix until we have proper bfd checks for the year
>>> 2038, if it makes sense.  64-bit hosts seems to be more common these days, so
>>> I'm not sure how important it is to have this support enabled and how soon
>>> we want to enable it.
>>
>> I don't understand: why offer a --enable-year2038 switch if using it
>> would produce a broken build?
> 
> That switch is already offered by gnulib since the recent import, and it is on by default. So in practice it produces a broken build for 32-bit hosts
> running a distro that understands 64-bit time_t. It's been broken for a while now.

Ah ok, I didn't understand that this configure switch was althread
provided by gnulib.  Makes sense.

> What I'm suggesting is having a temporary fix so default builds aren't silently broken due to a mismatch in stat size between GDB and BFD.
> 
> It isn't clear to me if we really want to switch to 64-bit time_t for 32-bit hosts at this point. There is potential for more breakage.

My opinion would be to follow the trend and use 64-bit everywhere, and
not have to worry about future-proofing anymore.  But I don't have any
stakes in this.

Simon

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Eli Zaretskii]

> Date: Mon, 1 Aug 2022 11:37:27 -0400
> From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
> 
> My opinion would be to follow the trend and use 64-bit everywhere, and
> not have to worry about future-proofing anymore.

That's not possible everywhere, though.

And I very much doubt that time has come for us to worry about the
year 2038.  Does anyone believe GDB 13 will still be used in that
year?

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Luis Machado]

On 8/1/22 16:59, Eli Zaretskii wrote:
>> Date: Mon, 1 Aug 2022 11:37:27 -0400
>> From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
>>
>> My opinion would be to follow the trend and use 64-bit everywhere, and
>> not have to worry about future-proofing anymore.
> 
> That's not possible everywhere, though.
> 
> And I very much doubt that time has come for us to worry about the
> year 2038.  Does anyone believe GDB 13 will still be used in that
> year?

I doubt it. There was some discussion here:

https://www.mail-archive.com/bug-gnulib@gnu.org/msg41057.html

I'm cc-ing Paul Eggert for additional considerations about this, but at the moment it seems the safest
is to just use 32-bit time_t for 32-bit hosts. There were some concerns about breaking compatibility if
we moved to 64-bit time_t on 32-bit hosts.

Maybe the best course of action is to get autoconf patched to support year2038 checks and then use that
in binutils-gdb.

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Luis Machado]

On 8/2/22 07:42, Luis Machado via Gdb-patches wrote:
> On 8/1/22 16:59, Eli Zaretskii wrote:
>>> Date: Mon, 1 Aug 2022 11:37:27 -0400
>>> From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
>>>
>>> My opinion would be to follow the trend and use 64-bit everywhere, and
>>> not have to worry about future-proofing anymore.
>>
>> That's not possible everywhere, though.
>>
>> And I very much doubt that time has come for us to worry about the
>> year 2038.  Does anyone believe GDB 13 will still be used in that
>> year?
> 
> I doubt it. There was some discussion here:
> 
> https://www.mail-archive.com/bug-gnulib@gnu.org/msg41057.html
> 
> I'm cc-ing Paul Eggert for additional considerations about this, but at the moment it seems the safest
> is to just use 32-bit time_t for 32-bit hosts. There were some concerns about breaking compatibility if
> we moved to 64-bit time_t on 32-bit hosts.
> 
> Maybe the best course of action is to get autoconf patched to support year2038 checks and then use that
> in binutils-gdb.

Any additional thoughts on this one?

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Eli Zaretskii]

> Date: Mon, 8 Aug 2022 12:34:02 +0100
> Cc: eggert@cs.ucla.edu, binutils@sourceware.org, gdb-patches@sourceware.org
> From: Luis Machado <luis.machado@arm.com>
> 
> On 8/2/22 07:42, Luis Machado via Gdb-patches wrote:
> > On 8/1/22 16:59, Eli Zaretskii wrote:
> >>> Date: Mon, 1 Aug 2022 11:37:27 -0400
> >>> From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
> >>>
> >>> My opinion would be to follow the trend and use 64-bit everywhere, and
> >>> not have to worry about future-proofing anymore.
> >>
> >> That's not possible everywhere, though.
> >>
> >> And I very much doubt that time has come for us to worry about the
> >> year 2038.  Does anyone believe GDB 13 will still be used in that
> >> year?
> > 
> > I doubt it. There was some discussion here:
> > 
> > https://www.mail-archive.com/bug-gnulib@gnu.org/msg41057.html
> > 
> > I'm cc-ing Paul Eggert for additional considerations about this, but at the moment it seems the safest
> > is to just use 32-bit time_t for 32-bit hosts. There were some concerns about breaking compatibility if
> > we moved to 64-bit time_t on 32-bit hosts.
> > 
> > Maybe the best course of action is to get autoconf patched to support year2038 checks and then use that
> > in binutils-gdb.
> 
> Any additional thoughts on this one?

What is the current plan if no one else chimes in?

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Luis Machado]

On 8/8/22 12:58, Eli Zaretskii wrote:
>> Date: Mon, 8 Aug 2022 12:34:02 +0100
>> Cc: eggert@cs.ucla.edu, binutils@sourceware.org, gdb-patches@sourceware.org
>> From: Luis Machado <luis.machado@arm.com>
>>
>> On 8/2/22 07:42, Luis Machado via Gdb-patches wrote:
>>> On 8/1/22 16:59, Eli Zaretskii wrote:
>>>>> Date: Mon, 1 Aug 2022 11:37:27 -0400
>>>>> From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
>>>>>
>>>>> My opinion would be to follow the trend and use 64-bit everywhere, and
>>>>> not have to worry about future-proofing anymore.
>>>>
>>>> That's not possible everywhere, though.
>>>>
>>>> And I very much doubt that time has come for us to worry about the
>>>> year 2038.  Does anyone believe GDB 13 will still be used in that
>>>> year?
>>>
>>> I doubt it. There was some discussion here:
>>>
>>> https://www.mail-archive.com/bug-gnulib@gnu.org/msg41057.html
>>>
>>> I'm cc-ing Paul Eggert for additional considerations about this, but at the moment it seems the safest
>>> is to just use 32-bit time_t for 32-bit hosts. There were some concerns about breaking compatibility if
>>> we moved to 64-bit time_t on 32-bit hosts.
>>>
>>> Maybe the best course of action is to get autoconf patched to support year2038 checks and then use that
>>> in binutils-gdb.
>>
>> Any additional thoughts on this one?
> 
> What is the current plan if no one else chimes in?

I'd like to push this temporary fix in so we can at least have a functional 32-bit Arm GDB on 32-bit hosts supporting
64-bit time_t. I expect other 32-bit GDB's will also potentially run into this.

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Eli Zaretskii]

> Date: Mon, 8 Aug 2022 13:04:58 +0100
> Cc: simark@simark.ca, eggert@cs.ucla.edu, binutils@sourceware.org,
>  gdb-patches@sourceware.org
> From: Luis Machado <luis.machado@arm.com>
> 
> >> Any additional thoughts on this one?
> > 
> > What is the current plan if no one else chimes in?
> 
> I'd like to push this temporary fix in so we can at least have a functional 32-bit Arm GDB on 32-bit hosts supporting
> 64-bit time_t. I expect other 32-bit GDB's will also potentially run into this.

I don't object to that.

Thanks.

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Nick Clifton]

Hi Luis,

> Thoughts?

If I have understood the comments on this thread, this patch represents
the best solution for now. So...

Patch approved - please apply.

Cheers
   Nick

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Paul Eggert]

On 8/1/22 23:42, Luis Machado wrote:
> 
> Maybe the best course of action is to get autoconf patched to support 
> year2038 checks and then use that
> in binutils-gdb.

Sorry, I'm a bit lost here.

GDB can already do what Gnulib's largefile module does; that's just some 
.m4 code. It sounds like you don't want GDB to do that, and instead want 
Autoconf to do something - presumably, modify Autoconf's 
AC_SYS_LARGEFILE to do the same thing that Gnulib's AC_SYS_LARGEFILE 
does). Although Autoconf could do that, I don't see why that would be be 
any better for GDB than GDB's using the equivalent of Gnulib's largefile 
module in GDB's ACX_LARGEFILE macro.

What am I missing?

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Luis Machado]

On 8/8/22 18:55, Paul Eggert wrote:
> On 8/1/22 23:42, Luis Machado wrote:
>>
>> Maybe the best course of action is to get autoconf patched to support year2038 checks and then use that
>> in binutils-gdb.
> 
> Sorry, I'm a bit lost here.
> 
> GDB can already do what Gnulib's largefile module does; that's just some .m4 code. It sounds like you don't want GDB to do that, and instead want Autoconf to do something - presumably, modify Autoconf's AC_SYS_LARGEFILE to do the same thing that Gnulib's AC_SYS_LARGEFILE does). Although Autoconf could do that, I don't see why that would be be any better for GDB than GDB's using the equivalent of Gnulib's largefile module in GDB's ACX_LARGEFILE macro.
> 
> What am I missing?

The missing part here is that although GDB can indeed use Gnulib's default "enable 64-bit time_t on 32-bit hosts" check, BFD doesn't use Gnulib and so won't know anything about 64-bit time_t. BFD uses autoconf's AC_SYS_LARGEFILE, which seems like a copy of Gnulib's AC_SYS_LARGEFILE, sort of.

Given there is some shared code between GDB and BFD using struct stat, for example, this leads to memory corruption due to the discrepancies in struct size.

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Luis Machado]

On 8/8/22 19:00, Luis Machado wrote:
> On 8/8/22 18:55, Paul Eggert wrote:
>> On 8/1/22 23:42, Luis Machado wrote:
>>>
>>> Maybe the best course of action is to get autoconf patched to support year2038 checks and then use that
>>> in binutils-gdb.
>>
>> Sorry, I'm a bit lost here.
>>
>> GDB can already do what Gnulib's largefile module does; that's just some .m4 code. It sounds like you don't want GDB to do that, and instead want Autoconf to do something - presumably, modify Autoconf's AC_SYS_LARGEFILE to do the same thing that Gnulib's AC_SYS_LARGEFILE does). Although Autoconf could do that, I don't see why that would be be any better for GDB than GDB's using the equivalent of Gnulib's largefile module in GDB's ACX_LARGEFILE macro.
>>
>> What am I missing?
> 
> The missing part here is that although GDB can indeed use Gnulib's default "enable 64-bit time_t on 32-bit hosts" check, BFD doesn't use Gnulib and so won't know anything about 64-bit time_t. BFD uses autoconf's AC_SYS_LARGEFILE, which seems like a copy of Gnulib's AC_SYS_LARGEFILE, sort of.

Let me ammend this, autoconf's AC_SYS_LARGEFILE *was* a copy of Gnulib, but now went out of sync without the year 2038 check. So BFD is left in the dark about the 64-bit time_t support for 32-bit hosts.

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Paul Eggert]

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

On 8/8/22 11:01, Luis Machado wrote:
> BFD is left in the dark about the 64-bit time_t support for 32-bit hosts.

OK, but how about if we fix that by syncing non-Gnulib-using code with 
Gnulib-using code? This should be relatively easy. Something like the 
first attached patch, say. If there's still interest in 32-bit binutils 
this would be a better approach. (If there's not, then we don't have to 
install any patch. :-)

PS. While looking into this I noticed a grep portability bug in a couple 
of 'configure.ac's, fixed in the 2nd attached patch.

PPS. I couldn't get a 32-bit version of binutils-gdb to build on Fedora 
x86-64, even without either of the attached patches. See the 3rd 
attached file, which is a compressed log of my attempt to build. Here's 
the first part of the failing output:

   /bin/sh ../libtool  --tag=CXX   --mode=link gcc -m32 -Wall -pthread 
-Wno-switch -g -O2       -o gp-archive gp-archive.o ArchiveExp.o 
libgprofng.la  -L../../zlib -lz
   libtool: link: gcc -m32 -Wall -pthread -Wno-switch -g -O2 -o 
gp-archive gp-archive.o ArchiveExp.o  ./.libs/libgprofng.a 
-L/home/eggert/src/gnu/build/zlib -L/home/eggert/src/gnu/build/libiberty 
/home/eggert/src/gnu/build/opcodes/.libs/libopcodes.a 
/home/eggert/src/gnu/build/bfd/.libs/libbfd.a -liberty -lpthread -ldl 
-lz -pthread
   /usr/bin/ld: gp-archive.o: in function `er_archive::check_args(int, 
char**)':
 
/home/eggert/src/gnu/build/gprofng/src/../../../binutils-gdb/gprofng/src/gp-archive.cc:573: 
undefined reference to `operator new(unsigned int)'

[-- Attachment #2: 0001-Use-the-same-_TIME_BITS-everywhere.patch --]
[-- Type: text/x-patch, Size: 1394 bytes --]

From 4809a5538015f82fdbe5aec5d6fdaab5fefa07ba Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 9 Aug 2022 07:44:49 -0700
Subject: [PATCH 1/2] Use the same _TIME_BITS everywhere

* largefile.m4: Include Gnulib's largefile.m4 and year2038.m4.
---
 config/ChangeLog    | 5 +++++
 config/largefile.m4 | 6 ++++++
 2 files changed, 11 insertions(+)

diff --git a/config/ChangeLog b/config/ChangeLog
index 3385292b3dc..f19422f27e7 100644
--- a/config/ChangeLog
+++ b/config/ChangeLog
@@ -1,3 +1,8 @@
+2022-08-09  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Use the same _TIME_BITS everywhere
+	* largefile.m4: Include Gnulib's largefile.m4 and year2038.m4.
+
 2022-07-08  Nick Clifton  <nickc@redhat.com>
 
 	* 2.39 branch created.
diff --git a/config/largefile.m4 b/config/largefile.m4
index 937596334cd..1521e7c59bd 100644
--- a/config/largefile.m4
+++ b/config/largefile.m4
@@ -3,6 +3,12 @@
 # bfd's configure script so that all the directories agree on the size
 # of structures used to describe files.
 
+# Use the same version of AC_SYS_LARGEFILE that Gnulib uses,
+# as it may set _FILE_OFFSET_BITS and/or _TIME_BITS and this
+# needs to be consistent across binutils.
+m4_include([../gnulib/import/m4/largefile.m4])
+m4_include([../gnulib/import/m4/year2038.m4])
+
 AC_DEFUN([ACX_LARGEFILE],[dnl
 
 # The tests for host and target for $enable_largefile require
-- 
2.37.1


[-- Attachment #3: 0002-Avoid-undefined-in-regexp.patch --]
[-- Type: text/x-patch, Size: 2238 bytes --]

From 4695c75036bb6c632baa646e4dd2d084d81b23f7 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 9 Aug 2022 07:48:25 -0700
Subject: [PATCH 2/2] Avoid undefined \- in regexp

* configure.ac, libiberty/configure.ac:
(AR_PLUGIN_OPTION, RANLIB_PLUGIN_OPTION):
Don't use 'grep "\-..."' as POSIX says the interpretation
of \- is undefined in a regular expression.
---
 ChangeLog              | 8 ++++++++
 configure.ac           | 4 ++--
 libiberty/configure.ac | 4 ++--
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 8a84e119e53..44b4233bde6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2022-08-09  Paul Eggert  <eggert@cs.ucla.edu>
+
+	Avoid undefined \- in regexp
+	* configure.ac, libiberty/configure.ac:
+	(AR_PLUGIN_OPTION, RANLIB_PLUGIN_OPTION):
+	Don't use 'grep "\-..."' as POSIX says the interpretation
+	of \- is undefined in a regular expression.
+
 2022-07-08  Nick Clifton  <nickc@redhat.com>
 
 	* 2.39 branch created.
diff --git a/configure.ac b/configure.ac
index 1651cbf3b02..4738294dbd9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3475,10 +3475,10 @@ GCC_PLUGIN_OPTION(PLUGIN_OPTION)
 AR_PLUGIN_OPTION=
 RANLIB_PLUGIN_OPTION=
 if test -n "$PLUGIN_OPTION"; then
-  if $AR --help 2>&1 | grep -q "\--plugin"; then
+  if $AR --help 2>&1 | grep -q "[-]-plugin"; then
     AR_PLUGIN_OPTION="$PLUGIN_OPTION"
   fi
-  if $RANLIB --help 2>&1 | grep -q "\--plugin"; then
+  if $RANLIB --help 2>&1 | grep -q "[-]-plugin"; then
     RANLIB_PLUGIN_OPTION="$PLUGIN_OPTION"
   fi
 else
diff --git a/libiberty/configure.ac b/libiberty/configure.ac
index 6c1ff9c6093..28933d5fcc1 100644
--- a/libiberty/configure.ac
+++ b/libiberty/configure.ac
@@ -116,11 +116,11 @@ AC_CHECK_TOOL(RANLIB, ranlib, :)
 
 GCC_PLUGIN_OPTION(PLUGIN_OPTION)
 if test -n "$PLUGIN_OPTION"; then
-  if $AR --help 2>&1 | grep -q "\--plugin"; then
+  if $AR --help 2>&1 | grep -q "[-]-plugin"; then
     AR_PLUGIN_OPTION="$PLUGIN_OPTION"
     AC_SUBST(AR_PLUGIN_OPTION)
   fi
-  if $RANLIB --help 2>&1 | grep -q "\--plugin"; then
+  if $RANLIB --help 2>&1 | grep -q "[-]-plugin"; then
     RANLIB_PLUGIN_OPTION="$PLUGIN_OPTION"
     AC_SUBST(RANLIB_PLUGIN_OPTION)
   fi
-- 
2.37.1


[-- Attachment #4: binutils-gdb-fedora-x86-64-32.txt.gz --]
[-- Type: application/gzip, Size: 52383 bytes --]

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Luis Machado]

On 8/9/22 16:49, Paul Eggert wrote:
> On 8/8/22 11:01, Luis Machado wrote:
>> BFD is left in the dark about the 64-bit time_t support for 32-bit hosts.
> 
> OK, but how about if we fix that by syncing non-Gnulib-using code with Gnulib-using code? This should be relatively easy. Something like the first attached patch, say. If there's still interest in 32-bit binutils this would be a better approach. (If there's not, then we don't have to install any patch. :-)

Sure, but that would make BFD use gnulib, which I don't think is desirable. I don't know why binutils has chosen not to use gnulib, but I'm assuming
the binutils community wouldn't like to pull gnulib code into it without discussing it first. My fix only disables gnulib's use of 64-bit time_t.

Nick, would you know the reason behind binutils not using gnulib?

> 
> PS. While looking into this I noticed a grep portability bug in a couple of 'configure.ac's, fixed in the 2nd attached patch.
> 

Thanks!

> PPS. I couldn't get a 32-bit version of binutils-gdb to build on Fedora x86-64, even without either of the attached patches. See the 3rd attached file, which is a compressed log of my attempt to build. Here's the first part of the failing output:
> 
>    /bin/sh ../libtool  --tag=CXX   --mode=link gcc -m32 -Wall -pthread -Wno-switch -g -O2       -o gp-archive gp-archive.o ArchiveExp.o libgprofng.la  -L../../zlib -lz
>    libtool: link: gcc -m32 -Wall -pthread -Wno-switch -g -O2 -o gp-archive gp-archive.o ArchiveExp.o  ./.libs/libgprofng.a -L/home/eggert/src/gnu/build/zlib -L/home/eggert/src/gnu/build/libiberty /home/eggert/src/gnu/build/opcodes/.libs/libopcodes.a /home/eggert/src/gnu/build/bfd/.libs/libbfd.a -liberty -lpthread -ldl -lz -pthread
>    /usr/bin/ld: gp-archive.o: in function `er_archive::check_args(int, char**)':
> 
> /home/eggert/src/gnu/build/gprofng/src/../../../binutils-gdb/gprofng/src/gp-archive.cc:573: undefined reference to `operator new(unsigned int)'

Some of the sub-projects within binutils-gdb are C++ now, so it seems this is attempting to build them with a C compiler.

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Paul Eggert]

On 8/9/22 08:59, Luis Machado wrote:

> that would make BFD use gnulib

Not really. BFD code would not use any Gnulib code as a result of that 
patch. It's merely a patch to how BFD is configured, not how it's run.

In other words, no source files under bfd/* change, and libbfd.a 
contains no Gnulib code and needs no Gnulib code.

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Eli Zaretskii]

> Date: Tue, 9 Aug 2022 08:49:53 -0700
> Cc: gdb-patches@sourceware.org, binutils@sourceware.org,
>  Eli Zaretskii <eliz@gnu.org>, Simon Marchi <simark@simark.ca>
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> PPS. I couldn't get a 32-bit version of binutils-gdb to build on Fedora 
> x86-64, even without either of the attached patches.

FTR, I regularly do such builds (on native MS-Windows), both the parts
used by GDB when I build GDB, and when I build Binutils themselves.  I
never had any trouble (with the caveat that I didn't yet build the
latest Binutils 3.29).

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Paul Eggert]

On 8/9/22 09:29, Eli Zaretskii wrote:
>> Date: Tue, 9 Aug 2022 08:49:53 -0700
>> From: Paul Eggert <eggert@cs.ucla.edu>
>>
>> PPS. I couldn't get a 32-bit version of binutils-gdb to build on Fedora
>> x86-64, even without either of the attached patches.
> 
> FTR, I regularly do such builds (on native MS-Windows), both the parts
> used by GDB when I build GDB, and when I build Binutils themselves.  I
> never had any trouble (with the caveat that I didn't yet build the
> latest Binutils 3.29).

Oh, I should make it clear that my failure was with bleeding-edge 
binutils-gdb, commit f56173071020d3e97c98c550ba6264122e5d861d dated Tue 
Aug 9 15:39:02 2022 +0100. My Fedora 36 platform had 
gcc-12.1.1-1.fc36.x86_64 and binutils-2.37-27.fc36.x86_64; I configured 
with CC='gcc -m32' CXX='gcc -m32' to cause the binutils-gdb build to be 
in 32-bit mode.

Hmm, likely that CXX was wrong and I should have used g++ not gcc. 
However, switching to g++ doesn't work either; when I configure it this way:

../binutils-gdb/configure CC='gcc -m32' CXX='g++ -m32'

the build still fails as follows, on both Fedora 36 and Ubuntu 22.04.1 
LTS (which uses GCC 11.2). So there's still something squirrelly going 
on with respect to 32-builds on GNU/Linux, which as I understand it are 
the only builds where these year-2038 fixes are relevant.

   CXX    linux-amd64-ipa.o

../../binutils-gdb/gdbserver/linux-amd64-ipa.cc: In function ‘const 
target_desc* get_ipa_tdesc(int)’:

../../binutils-gdb/gdbserver/linux-amd64-ipa.cc:201:14: error: 
‘amd64_linux_read_description’ was not declared in this scope; did you 
mean ‘i386_linux_read_description’?

   201 |       return amd64_linux_read_description (X86_XSTATE_SSE_MASK, 
true);

       |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

       |              i386_linux_read_description

../../binutils-gdb/gdbserver/linux-amd64-ipa.cc: In function ‘void 
initialize_low_tracepoint()’:

../../binutils-gdb/gdbserver/linux-amd64-ipa.cc:282:3: error: 
‘amd64_linux_read_description’ was not declared in this scope; did you 
mean ‘i386_linux_read_description’?

   282 |   amd64_linux_read_description (X86_XSTATE_SSE_MASK, true);

       |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

       |   i386_linux_read_description

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Alan Modra]

On Tue, Aug 09, 2022 at 10:02:16AM -0700, Paul Eggert wrote:
> Hmm, likely that CXX was wrong and I should have used g++ not gcc. However,
> switching to g++ doesn't work either; when I configure it this way:
> 
> ../binutils-gdb/configure CC='gcc -m32' CXX='g++ -m32'

I regularly build bleeding edge binutils on an x86_64-linux Ubuntu
22.04 box with 32-bit libraries installed using:

CC="gcc -m32" CXX="g++ -m32" \
~/src/binutils-gdb/configure --build=i686-linux --enable-targets=all \
--enable-gold --enable-threads \
--disable-gdb --disable-gdbserver --disable-sim --disable-readline \
--disable-libdecnumber --disable-libbacktrace --disable-gprofng --disable-nls

I'm not sure now why I had --build there rather than --target,
probably something to do with getting more "make check" tests run.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Nick Clifton]

Hi Luis,

> Nick, would you know the reason behind binutils not using gnulib?

Originally it was historical - the binutils project was started a
long time before the gnulib project.

These days it is an effort issue - as in it will take a lot of effort
to switch over to using gnulib, and I just do not have the time.  But
if someone else is interested in doing the work then I am not against
it.

There may be some technical issue - I seem to remember seeing some
posts in the past about problems with gnulib - but these can probably
be resolved.  Also I am not sure about the state of the documentation
for gnulib.  If it is minimal, as the gnulib project's web page
suggests, then this is going to hinder adoption into the binutils.

Cheers
   Nick

Re: [PATCH] Disable year 2038 support on 32-bit hosts by default

[Luis Machado]

On 8/10/22 10:41, Nick Clifton wrote:
> Hi Luis,
> 
>> Nick, would you know the reason behind binutils not using gnulib?
> 
> Originally it was historical - the binutils project was started a
> long time before the gnulib project.
> 
> These days it is an effort issue - as in it will take a lot of effort
> to switch over to using gnulib, and I just do not have the time.  But
> if someone else is interested in doing the work then I am not against
> it.
> 
> There may be some technical issue - I seem to remember seeing some
> posts in the past about problems with gnulib - but these can probably
> be resolved.  Also I am not sure about the state of the documentation
> for gnulib.  If it is minimal, as the gnulib project's web page
> suggests, then this is going to hinder adoption into the binutils.
> 
> Cheers
>    Nick
> 

Thanks for the feedback. I don't want to introduce more issues, so I'll go with
the original patch that just creates a root level enable/disable switch for the year 2038 fix.

It will be disabled by default for now.

Regards,
Luis