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

[Luis Machado <luis.machado@arm.com>]

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.