[ptxdist] year 2038 Toolchain

[ptxdist] year 2038 Toolchain

[Erwin Rol]

Hey all,

I am working on arm32 (imx6ul) and need to support dates beyond 2038. 
With the new ptxdist 2038 support it seems to work in C, but I ran into 
problems with C++.

The following code;

auto t = std::chrono::system_clock::now();

does not seem to work correctly. When the system date is less than 2038 
it works and gives back the correct time, but for dates > 2038 it seems 
to return some 1970 date.

Conversion functions on the other hand seem to work;

auto t = std::chrono::system_clock::from_time_t(time(nullptr));

does a correct conversion of dates > 2038.

The defines like _TIME_BITS=64 are set correctly, and time_t is 64bit. 
Also calls like gettimeofday() works correctly.

Since the C++ std lib is part of the Toolchain, can it be that the 
Toolchain is not build correctly ?

Anybody any experience with y2038 in C++ on ptxdist ?

best regards,

Erwin

Re: [ptxdist] year 2038 Toolchain

[Ian Abbott]

On 23/05/2024 07:41, Erwin Rol wrote:
> Hey all,
> 
> I am working on arm32 (imx6ul) and need to support dates beyond 2038. 
> With the new ptxdist 2038 support it seems to work in C, but I ran into 
> problems with C++.
> 
> The following code;
> 
> auto t = std::chrono::system_clock::now();
> 
> does not seem to work correctly. When the system date is less than 2038 
> it works and gives back the correct time, but for dates > 2038 it seems 
> to return some 1970 date.
> 
> Conversion functions on the other hand seem to work;
> 
> auto t = std::chrono::system_clock::from_time_t(time(nullptr));
> 
> does a correct conversion of dates > 2038.
> 
> The defines like _TIME_BITS=64 are set correctly, and time_t is 64bit. 
> Also calls like gettimeofday() works correctly.
> 
> Since the C++ std lib is part of the Toolchain, can it be that the 
> Toolchain is not build correctly ?
> 
> Anybody any experience with y2038 in C++ on ptxdist ?
> 
> best regards,
> 
> Erwin
> 

I guess that libstdc++ in the toolchain would need to be rebuilt with 
64-bit time_t support.  Although <chrono> uses a 64-bit integer type 
internally, some of the functions such as 
std::chrono::system_clock::now() use compiled in code that picks up the 
C system time ABI at the time libstdc++ was built.  So now() will read 
the system time using the 32-bit system time ABI (so will suffer from 
Y2038 problems) and convert it to its own internal 64-bit integer type. 
Other functions such as 
std::chrono::system_clock::from_time_t(std::time_t) are not compiled in 
so will use whatever C system time ABI was selected when <chrono> was 
included.

-- 
-=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company  )=-
-=( registered in England & Wales.  Regd. number: 02862268.  )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-

Re: [ptxdist] year 2038 Toolchain

[Erwin Rol]

On 5/23/24 12:38, Ian Abbott wrote:
> On 23/05/2024 07:41, Erwin Rol wrote:

>> The following code;
>>
>> auto t = std::chrono::system_clock::now();
>>
>> does not seem to work correctly. When the system date is less than 
>> 2038 it works and gives back the correct time, but for dates > 2038 it 
>> seems to return some 1970 date.
>>
> 
> I guess that libstdc++ in the toolchain would need to be rebuilt with 
> 64-bit time_t support.  Although <chrono> uses a 64-bit integer type 
> internally, some of the functions such as 
> std::chrono::system_clock::now() use compiled in code that picks up the 
> C system time ABI at the time libstdc++ was built.  So now() will read 
> the system time using the 32-bit system time ABI (so will suffer from 
> Y2038 problems) and convert it to its own internal 64-bit integer type. 
> Other functions such as 
> std::chrono::system_clock::from_time_t(std::time_t) are not compiled in 
> so will use whatever C system time ABI was selected when <chrono> was 
> included.
> 

I believe libstd++ uses gettimeofday internally, which should use time_t 
for the seconds field, which should be 64bit if _TIME_BITS=64 is 
defined. I just hacked the Toolchain to try it, but it is a slow 
process, build toolchain -> build project -> test :-)

If I figure it out I'll let you guys know (so it can be added to the 
official Toolchain)

- Erwin

Re: [ptxdist] year 2038 Toolchain

[Ian Abbott]

On 23/05/2024 12:52, Erwin Rol wrote:
> On 5/23/24 12:38, Ian Abbott wrote:
>> On 23/05/2024 07:41, Erwin Rol wrote:
> 
>>> The following code;
>>>
>>> auto t = std::chrono::system_clock::now();
>>>
>>> does not seem to work correctly. When the system date is less than 
>>> 2038 it works and gives back the correct time, but for dates > 2038 
>>> it seems to return some 1970 date.
>>>
>>
>> I guess that libstdc++ in the toolchain would need to be rebuilt with 
>> 64-bit time_t support.  Although <chrono> uses a 64-bit integer type 
>> internally, some of the functions such as 
>> std::chrono::system_clock::now() use compiled in code that picks up 
>> the C system time ABI at the time libstdc++ was built.  So now() will 
>> read the system time using the 32-bit system time ABI (so will suffer 
>> from Y2038 problems) and convert it to its own internal 64-bit integer 
>> type. Other functions such as 
>> std::chrono::system_clock::from_time_t(std::time_t) are not compiled 
>> in so will use whatever C system time ABI was selected when <chrono> 
>> was included.
>>
> 
> I believe libstd++ uses gettimeofday internally, which should use time_t 
> for the seconds field, which should be 64bit if _TIME_BITS=64 is 
> defined. I just hacked the Toolchain to try it, but it is a slow 
> process, build toolchain -> build project -> test :-)
> 
> If I figure it out I'll let you guys know (so it can be added to the 
> official Toolchain)

Rememember to define _FILE_OFFSET_BITS=64 too if it is not already 
defined. _TIME_BITS=64 is ineffective when _FILE_OFFSET_BITS=32 for 
Glibc policy reasons.

-- 
-=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company  )=-
-=( registered in England & Wales.  Regd. number: 02862268.  )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-

Re: [ptxdist] year 2038 Toolchain

[Erwin Rol]

On 5/24/24 10:41, Ian Abbott wrote:

>> If I figure it out I'll let you guys know (so it can be added to the 
>> official Toolchain)
> 
> Rememember to define _FILE_OFFSET_BITS=64 too if it is not already 
> defined. _TIME_BITS=64 is ineffective when _FILE_OFFSET_BITS=32 for 
> Glibc policy reasons.

I tried some things to convince the Toolchain project (latest gcc13 
release) to use those two defines, but without much luck. Sometimes 
parts complained that there were duplicate declarations of (time) 
functions, with some other tries it actually complained the the 
_FILE_OFFSET_BITS was missing for some part, that I really don't 
understand because I added them always in pairs.

So I believe it is just a bit too early for 100% year 2038 compliance at 
the moment. Especially when it comes to C++/libstd++ there is also not 
much info online.

But the C part seems to work with the support ptxdist offers, and C++ 
has always been some unwanted stepchild, especially now Rust is going to 
safe the world :-)

- Erwin

Re: [ptxdist] year 2038 Toolchain

[Michael Olbrich]

On Fri, May 24, 2024 at 11:04:24AM +0200, Erwin Rol wrote:
> On 5/24/24 10:41, Ian Abbott wrote:
> 
> > > If I figure it out I'll let you guys know (so it can be added to the
> > > official Toolchain)
> > 
> > Rememember to define _FILE_OFFSET_BITS=64 too if it is not already
> > defined. _TIME_BITS=64 is ineffective when _FILE_OFFSET_BITS=32 for
> > Glibc policy reasons.
> 
> I tried some things to convince the Toolchain project (latest gcc13 release)
> to use those two defines, but without much luck. Sometimes parts complained
> that there were duplicate declarations of (time) functions, with some other
> tries it actually complained the the _FILE_OFFSET_BITS was missing for some
> part, that I really don't understand because I added them always in pairs.
> 
> So I believe it is just a bit too early for 100% year 2038 compliance at the
> moment. Especially when it comes to C++/libstd++ there is also not much info
> online.
> 
> But the C part seems to work with the support ptxdist offers, and C++ has
> always been some unwanted stepchild, especially now Rust is going to safe
> the world :-)

So gcc-14 has a --enable-year2038 configure option, but I didn't test if it
works.

But I don't know if that causes any API or ABI incompatibilities.
The changelog says "Disable year2038 by default on 32-bit hosts.". That
looks a bit suspicious to me.

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [ptxdist] year 2038 Toolchain

[Erwin Rol]

On 5/24/24 12:19, Michael Olbrich wrote:
> On Fri, May 24, 2024 at 11:04:24AM +0200, Erwin Rol wrote:
>> On 5/24/24 10:41, Ian Abbott wrote:
>>
>>>> If I figure it out I'll let you guys know (so it can be added to the
>>>> official Toolchain)
>>>
>>> Rememember to define _FILE_OFFSET_BITS=64 too if it is not already
>>> defined. _TIME_BITS=64 is ineffective when _FILE_OFFSET_BITS=32 for
>>> Glibc policy reasons.
>>
>> I tried some things to convince the Toolchain project (latest gcc13 release)
>> to use those two defines, but without much luck. Sometimes parts complained
>> that there were duplicate declarations of (time) functions, with some other
>> tries it actually complained the the _FILE_OFFSET_BITS was missing for some
>> part, that I really don't understand because I added them always in pairs.
>>
>> So I believe it is just a bit too early for 100% year 2038 compliance at the
>> moment. Especially when it comes to C++/libstd++ there is also not much info
>> online.
>>
>> But the C part seems to work with the support ptxdist offers, and C++ has
>> always been some unwanted stepchild, especially now Rust is going to safe
>> the world :-)
> 
> So gcc-14 has a --enable-year2038 configure option, but I didn't test if it
> works.

Any ETA for a gcc14 ptxdist Toolchain ?

> But I don't know if that causes any API or ABI incompatibilities.
> The changelog says "Disable year2038 by default on 32-bit hosts.". That
> looks a bit suspicious to me.

Maybe make 2 specific 32bit toolchains, one with TIME_BITS=32 and one 
with TIME_BITS=64? So ppl (like me) can start testing the TIME_BITS=64 
version, and ppl that know for sure they do not care about y2038 can 
keep using the TIME_BITS=32 version ?

- Erwin

Re: [ptxdist] year 2038 Toolchain

[Christian Melki]

Hello Erwin.

On 5/27/24 10:32 AM, Erwin Rol wrote:
> [You don't often get email from mailinglists@erwinrol.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On 5/24/24 12:19, Michael Olbrich wrote:
>> On Fri, May 24, 2024 at 11:04:24AM +0200, Erwin Rol wrote:
>>> On 5/24/24 10:41, Ian Abbott wrote:
>>>
>>>>> If I figure it out I'll let you guys know (so it can be added to the
>>>>> official Toolchain)
>>>>
>>>> Rememember to define _FILE_OFFSET_BITS=64 too if it is not already
>>>> defined. _TIME_BITS=64 is ineffective when _FILE_OFFSET_BITS=32 for
>>>> Glibc policy reasons.
>>>
>>> I tried some things to convince the Toolchain project (latest gcc13 release)
>>> to use those two defines, but without much luck. Sometimes parts complained
>>> that there were duplicate declarations of (time) functions, with some other
>>> tries it actually complained the the _FILE_OFFSET_BITS was missing for some
>>> part, that I really don't understand because I added them always in pairs.
>>>
>>> So I believe it is just a bit too early for 100% year 2038 compliance at the
>>> moment. Especially when it comes to C++/libstd++ there is also not much info
>>> online.
>>>
>>> But the C part seems to work with the support ptxdist offers, and C++ has
>>> always been some unwanted stepchild, especially now Rust is going to safe
>>> the world :-)
>>
>> So gcc-14 has a --enable-year2038 configure option, but I didn't test if it
>> works.
> 
> Any ETA for a gcc14 ptxdist Toolchain ?
> 

You can always roll your own toolchain?
Esp. If you need to test things. ct-ng toolchains work pretty much as is.
Atleast that's what I always do.

>> But I don't know if that causes any API or ABI incompatibilities.
>> The changelog says "Disable year2038 by default on 32-bit hosts.". That
>> looks a bit suspicious to me.
> 
> Maybe make 2 specific 32bit toolchains, one with TIME_BITS=32 and one
> with TIME_BITS=64? So ppl (like me) can start testing the TIME_BITS=64
> version, and ppl that know for sure they do not care about y2038 can
> keep using the TIME_BITS=32 version ?
> 
> - Erwin
> 

Regards,
Christian

[ptxdist] year 2038 Toolchain

[Erwin Rol]

Hey all,

I am working on arm32 (imx6ul) and need to support dates beyond 2038. 
With the new ptxdist 2038 support it seems to work in C, but I ran into 
problems with C++.

The following code;

auto t = std::chrono::system_clock::now();

does not seem to work correctly. When the system date is less than 2038 
it works and gives back the correct time, but for dates > 2038 it seems 
to return some 1970 date.

Conversion functions on the other hand seem to work;

auto t = std::chrono::system_clock::from_time_t(time(nullptr));

does a correct conversion of dates > 2038.

The defines like _TIME_BITS=64 are set correctly, and time_t is 64bit. 
Also calls like gettimeofday() works correctly.

Since the C++ std lib is part of the Toolchain, can it be that the 
Toolchain is not build correctly ?

Anybody any experience with y2038 in C++ on ptxdist ?

best regards,

Erwin