[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