Re: [PATCH] Fix disabling of year 2038 support on 32-bit hosts by default

Re: [PATCH] Fix disabling of year 2038 support on 32-bit hosts by default

[Thiago Jung Bauermann]

Sorry, I forgot to cc: the binutils mailing list. Done now.

Thiago Jung Bauermann <thiago.bauermann@linaro.org> writes:

> Commit e5f2f7d901ee ("Disable year 2038 support on 32-bit hosts by
> default") fixed a mismatch between 64-bit time_t in GDB and system headers
> and 32-bit time_t in BFD.
>
> However, since commit 862776f26a59 ("Finalized intl-update patches")
> gnulib's year 2038 support has been accidentally re-enabled — causing
> problems for 32-bit hosts again.  The commit split baseargs into
> {h,b}baseargs, but this hasn't been done for the code that handles
> --disable-year2038.
>
> This patch restores the intended behaviour.  With this change, the number
> of unexpected core files goes from 18 to 4.
>
> Tested on armv8l-linux-gnueabihf.
> ---
>  configure    | 3 ++-
>  configure.ac | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index 670684d83d15..6466b97f3ec0 100755
> --- a/configure
> +++ b/configure
> @@ -10313,7 +10313,8 @@ hbaseargs="$hbaseargs --disable-option-checking"
>  tbaseargs="$tbaseargs --disable-option-checking"
>  
>  if test "$enable_year2038" = no; then
> -  baseargs="$baseargs --disable-year2038"
> +  bbaseargs="$bbaseargs --disable-year2038"
> +  hbaseargs="$hbaseargs --disable-year2038"
>    tbaseargs="$tbaseargs --disable-year2038"
>  fi
>  
> diff --git a/configure.ac b/configure.ac
> index 88b4800e298f..1300a805fd8d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -3432,7 +3432,8 @@ hbaseargs="$hbaseargs --disable-option-checking"
>  tbaseargs="$tbaseargs --disable-option-checking"
>  
>  if test "$enable_year2038" = no; then
> -  baseargs="$baseargs --disable-year2038"
> +  bbaseargs="$bbaseargs --disable-year2038"
> +  hbaseargs="$hbaseargs --disable-year2038"
>    tbaseargs="$tbaseargs --disable-year2038"
>  fi
>  


-- 
Thiago

Re: [PATCH] Fix disabling of year 2038 support on 32-bit hosts by default

[Mark Wielaard]

Hi Thiago,

On Sat, Feb 03, 2024 at 01:39:15PM -0300, Thiago Jung Bauermann wrote:
> Thiago Jung Bauermann <thiago.bauermann@linaro.org> writes:
> 
> > Commit e5f2f7d901ee ("Disable year 2038 support on 32-bit hosts by
> > default") fixed a mismatch between 64-bit time_t in GDB and system headers
> > and 32-bit time_t in BFD.
> >
> > However, since commit 862776f26a59 ("Finalized intl-update patches")
> > gnulib's year 2038 support has been accidentally re-enabled — causing
> > problems for 32-bit hosts again.  The commit split baseargs into
> > {h,b}baseargs, but this hasn't been done for the code that handles
> > --disable-year2038.
> >
> > This patch restores the intended behaviour.  With this change, the number
> > of unexpected core files goes from 18 to 4.
> >
> > Tested on armv8l-linux-gnueabihf.

Thanks, this was also why the debian-i386-gdb builder was failing,
which is fixed with this patch! I had been scratching my head for some
time where this failure was coming from (it started when upgrading
debian).

https://builder.sourceware.org/buildbot/#/builders/105/builds/5890

Cheers,

Mark

Re: [PATCH] Fix disabling of year 2038 support on 32-bit hosts by default

[Luis Machado]

cc-ing binutils@ as well.

On 2/3/24 03:14, Thiago Jung Bauermann wrote:
> Commit e5f2f7d901ee ("Disable year 2038 support on 32-bit hosts by
> default") fixed a mismatch between 64-bit time_t in GDB and system headers
> and 32-bit time_t in BFD.
> 
> However, since commit 862776f26a59 ("Finalized intl-update patches")
> gnulib's year 2038 support has been accidentally re-enabled — causing
> problems for 32-bit hosts again.  The commit split baseargs into
> {h,b}baseargs, but this hasn't been done for the code that handles
> --disable-year2038.

Ouch. That's unfortunate. That was an annoying bug to chase. Thanks for chasing it (again).

> 
> This patch restores the intended behaviour.  With this change, the number
> of unexpected core files goes from 18 to 4.
> 
> Tested on armv8l-linux-gnueabihf.
> ---
>  configure    | 3 ++-
>  configure.ac | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/configure b/configure
> index 670684d83d15..6466b97f3ec0 100755
> --- a/configure
> +++ b/configure
> @@ -10313,7 +10313,8 @@ hbaseargs="$hbaseargs --disable-option-checking"
>  tbaseargs="$tbaseargs --disable-option-checking"
>  
>  if test "$enable_year2038" = no; then
> -  baseargs="$baseargs --disable-year2038"
> +  bbaseargs="$bbaseargs --disable-year2038"
> +  hbaseargs="$hbaseargs --disable-year2038"
>    tbaseargs="$tbaseargs --disable-year2038"
>  fi
>  
> diff --git a/configure.ac b/configure.ac
> index 88b4800e298f..1300a805fd8d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -3432,7 +3432,8 @@ hbaseargs="$hbaseargs --disable-option-checking"
>  tbaseargs="$tbaseargs --disable-option-checking"
>  
>  if test "$enable_year2038" = no; then
> -  baseargs="$baseargs --disable-year2038"
> +  bbaseargs="$bbaseargs --disable-year2038"
> +  hbaseargs="$hbaseargs --disable-year2038"
>    tbaseargs="$tbaseargs --disable-year2038"
>  fi
>  

Approved-By: Luis Machado <luis.machado@arm.com>

Re: [PATCH] Fix disabling of year 2038 support on 32-bit hosts by default

[Thiago Jung Bauermann]

Hello Luis,

Luis Machado <luis.machado@arm.com> writes:

> cc-ing binutils@ as well.
>
> On 2/3/24 03:14, Thiago Jung Bauermann wrote:
>> Commit e5f2f7d901ee ("Disable year 2038 support on 32-bit hosts by
>> default") fixed a mismatch between 64-bit time_t in GDB and system headers
>> and 32-bit time_t in BFD.
>> 
>> However, since commit 862776f26a59 ("Finalized intl-update patches")
>> gnulib's year 2038 support has been accidentally re-enabled — causing
>> problems for 32-bit hosts again.  The commit split baseargs into
>> {h,b}baseargs, but this hasn't been done for the code that handles
>> --disable-year2038.
>
> Ouch. That's unfortunate. That was an annoying bug to chase. Thanks for chasing it
> (again).

No problem. It was much easier the second time around, of course.

>> This patch restores the intended behaviour.  With this change, the number
>> of unexpected core files goes from 18 to 4.
>> 
>> Tested on armv8l-linux-gnueabihf.
>> ---
>>  configure    | 3 ++-
>>  configure.ac | 3 ++-
>>  2 files changed, 4 insertions(+), 2 deletions(-)
>> 
>> diff --git a/configure b/configure
>> index 670684d83d15..6466b97f3ec0 100755
>> --- a/configure
>> +++ b/configure
>> @@ -10313,7 +10313,8 @@ hbaseargs="$hbaseargs --disable-option-checking"
>>  tbaseargs="$tbaseargs --disable-option-checking"
>>  
>>  if test "$enable_year2038" = no; then
>> -  baseargs="$baseargs --disable-year2038"
>> +  bbaseargs="$bbaseargs --disable-year2038"
>> +  hbaseargs="$hbaseargs --disable-year2038"
>>    tbaseargs="$tbaseargs --disable-year2038"
>>  fi
>>  
>> diff --git a/configure.ac b/configure.ac
>> index 88b4800e298f..1300a805fd8d 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -3432,7 +3432,8 @@ hbaseargs="$hbaseargs --disable-option-checking"
>>  tbaseargs="$tbaseargs --disable-option-checking"
>>  
>>  if test "$enable_year2038" = no; then
>> -  baseargs="$baseargs --disable-year2038"
>> +  bbaseargs="$bbaseargs --disable-year2038"
>> +  hbaseargs="$hbaseargs --disable-year2038"
>>    tbaseargs="$tbaseargs --disable-year2038"
>>  fi
>>  
>
> Approved-By: Luis Machado <luis.machado@arm.com>

Thanks! Since this is a patch for the repository top-level, is your
approval sufficient to commit the patch, or should I have approval from
a binutils maintainer as well?

-- 
Thiago

Re: [PATCH] Fix disabling of year 2038 support on 32-bit hosts by default

[Thiago Jung Bauermann]

Thiago Jung Bauermann <thiago.bauermann@linaro.org> writes:

> Hello Luis,
>
> Luis Machado <luis.machado@arm.com> writes:
>>
>> Approved-By: Luis Machado <luis.machado@arm.com>
>
> Thanks! Since this is a patch for the repository top-level, is your
> approval sufficient to commit the patch, or should I have approval from
> a binutils maintainer as well?

Answering my own question: binutils/MAINTAINERS says:

  GDB global maintainers also have permission to commit and approve
  patches to the top level files and to those parts of bfd files
  primarily used by GDB.

So pushed as commit 9c0aa4c53104.

-- 
Thiago

Re: [PATCH] Fix disabling of year 2038 support on 32-bit hosts by default

[Andrew Pinski]

On Mon, Feb 5, 2024 at 10:40 AM Thiago Jung Bauermann
<thiago.bauermann@linaro.org> wrote:
>
>
> Thiago Jung Bauermann <thiago.bauermann@linaro.org> writes:
>
> > Hello Luis,
> >
> > Luis Machado <luis.machado@arm.com> writes:
> >>
> >> Approved-By: Luis Machado <luis.machado@arm.com>
> >
> > Thanks! Since this is a patch for the repository top-level, is your
> > approval sufficient to commit the patch, or should I have approval from
> > a binutils maintainer as well?
>
> Answering my own question: binutils/MAINTAINERS says:
>
>   GDB global maintainers also have permission to commit and approve
>   patches to the top level files and to those parts of bfd files
>   primarily used by GDB.
>
> So pushed as commit 9c0aa4c53104.


Please also submit/commit to the gcc trunk too since the toplevel
configure should be insync between the 2 repos.

Thanks,
Andrew

>
> --
> Thiago

Re: [PATCH] Fix disabling of year 2038 support on 32-bit hosts by default

[Thiago Jung Bauermann]

Hello Andrew,

Andrew Pinski <pinskia@gmail.com> writes:

> On Mon, Feb 5, 2024 at 10:40 AM Thiago Jung Bauermann
> <thiago.bauermann@linaro.org> wrote:
>>
>>
>> Thiago Jung Bauermann <thiago.bauermann@linaro.org> writes:
>>
>> > Hello Luis,
>> >
>> > Luis Machado <luis.machado@arm.com> writes:
>> >>
>> >> Approved-By: Luis Machado <luis.machado@arm.com>
>> >
>> > Thanks! Since this is a patch for the repository top-level, is your
>> > approval sufficient to commit the patch, or should I have approval from
>> > a binutils maintainer as well?
>>
>> Answering my own question: binutils/MAINTAINERS says:
>>
>>   GDB global maintainers also have permission to commit and approve
>>   patches to the top level files and to those parts of bfd files
>>   primarily used by GDB.
>>
>> So pushed as commit 9c0aa4c53104.
>
> Please also submit/commit to the gcc trunk too since the toplevel
> configure should be insync between the 2 repos.

I don't have commit access to the gcc repo so I sent a patch to the
gcc-patches mailing list.

-- 
Thiago