| Message ID | 20230807105935.2098236-12-arsen@aarsen.me |
|---|---|
| State | New |
| Headers | show |
| Series | Sync shared build infrastructure with binutils-gdb | expand |
On 8/7/23 04:32, Arsen Arsenović via Gcc-patches wrote: > From: Luis Machado <luis.machado@arm.com> > > 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? > > ChangeLog: > > * configure.ac: Disable year2038 by default on 32-bit hosts. > * configure: Regenerate. OK. Though I thought gnulib ended up reverting some of this work. Jeff
On 8/7/23 18:45, Jeff Law wrote: > > > On 8/7/23 04:32, Arsen Arsenović via Gcc-patches wrote: >> From: Luis Machado <luis.machado@arm.com> >> >> 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? >> >> ChangeLog: >> >> * configure.ac: Disable year2038 by default on 32-bit hosts. >> * configure: Regenerate. > OK. Though I thought gnulib ended up reverting some of this work. > > Jeff I sent this a little while ago. It may be possible that things have changed in gnulib since then. This was mostly addressing issues building binutils-gdb with a 32-bit hosts and enabling all targets.
diff --git a/configure b/configure index 35c0c75ee12..faa1aedaa04 100755 --- a/configure +++ b/configure @@ -809,6 +809,7 @@ enable_ld enable_gprofng enable_compressed_debug_sections enable_default_compressed_debug_sections_algorithm +enable_year2038 enable_libquadmath enable_libquadmath_support enable_libada @@ -1552,6 +1553,7 @@ Optional Features: --enable-default-compressed-debug-sections-algorithm={zlib,zstd} Default compression algorithm for --enable-compressed-debug-sections. + --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 @@ -3194,6 +3196,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 : @@ -10215,9 +10231,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 71b923d316f..a0dff0ecac8 100644 --- a/configure.ac +++ b/configure.ac @@ -459,6 +459,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], @@ -3339,9 +3351,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])
From: Luis Machado <luis.machado@arm.com> 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? ChangeLog: * configure.ac: Disable year2038 by default on 32-bit hosts. * configure: Regenerate. --- configure | 22 ++++++++++++++++++++++ configure.ac | 18 ++++++++++++++++++ 2 files changed, 40 insertions(+)