[ptxdist] libstdc++ and Y2038 (was: [ANNOUNCE] OSELAS.Toolchain() 2024.11.0 released)

[Michael Olbrich <m.olbrich@pengutronix.de>]

Hi,

On Wed, Nov 13, 2024 at 02:25:23PM +0100, Michael Olbrich wrote:
> On Wed, Nov 13, 2024 at 12:48:13PM +0000, Ian Abbott wrote:
> > On 13/11/2024 12:09, Michael Olbrich wrote:
> > > I'm happy to announce that I've just released OSELAS.Toolchain-2024.11.0.
> > > 
> > > This is a major release with significant changes. All components of the
> > > primary toolchains have been updated to the latest versions. The highlights
> > > are:
> > >   - binutils 2.43.1
> > >   - clang 19.1.3
> > >   - gcc 14.2
> > >   - gdb 15.2
> > >   - glibc 2.40
> > >   - kernel headers 6.11.6
> > >   - rustc 1.82.0
> > > 
> > > Beyond that, glibc is now built with more hardening features enabled,
> > > specifically --enable-bind-now and --enable-fortify-source.
> > > 
> > > The debug sections in all target libraries are now zstd compressed. And ld
> > > will use that by default with --compress-debug-sections.
> > > 
> > > The minimum kernel version that glibc will run on is now v5.15.
> > > 
> > > Download the release here:
> > > https://public.pengutronix.de/oselas/toolchain/
> > > 
> > > Debian / Ubuntu Packages will be available at
> > > http://debian.pengutronix.de/
> > > 
> > > My current plan is to build packages for Debian trixie/sid, bookworm,
> > > and Ubuntu 22.04, 24.04. The packages will show up in the near future.
> > > 
> > 
> > Thanks for the release.  A "nice to have" would have been 64-bit time_t
> > support in 32-bit libstdc++ to tick off one more box for Y2038 support.
> > There was some discussion about this earlier this year:
> > 
> > https://lore.ptxdist.org/ptxdist/24f03e42-a9ab-4303-9d0e-3b1ff24e0097@erwinrol.com/
> 
> Arg, I completely forgot about that. Sorry about that. You should have said
> something when I wrote about doing a new release last month...

So I looked at the --enable-year2038 option and it does nothing at all from
what I can tell. It seems to be an artifact of sharing stuff from the
binutils-gdb repo.

So the big question is: Is time_t somewhere hidden in the ABI?

I did find on bug report[1], but that's in a header, an if the whole BSP is
build with _TIME_BITS=64 then this is not a problem.

There is little to no information on this topic. In another bug report[2],
someone claims that at libfortran does not contain time_t in its ABI, but I
found nothing about libstdc++.

I did some tests with abi-compliance-checker and I think libstdc++.so looks
good, but I'm not 100% sure that what I did is correct. So this needs some
more investigation.

If you want to try it, the change I made is pretty simple:
---------------------------------------------------------------------------
diff --git a/rules/cross-gcc.make b/rules/cross-gcc.make
index 5643dc8a34e2..f8632259b8f0 100644
--- a/rules/cross-gcc.make
+++ b/rules/cross-gcc.make
@@ -95,8 +95,8 @@ CROSS_GCC_AUTOCONF_COMMON += \
 	--enable-libstdcxx-debug-flags="-gdwarf-4 -O0 -D_GLIBCXX_ASSERTIONS $(call ptx/toolchain-cross-debug-flags, CROSS_GCC)"
 
 CROSS_GCC_CONF_ENV += \
-	CFLAGS_FOR_TARGET="$(call ptx/toolchain-cross-debug-flags, CROSS_GCC)" \
-	CXXFLAGS_FOR_TARGET="$(call ptx/toolchain-cross-debug-flags, CROSS_GCC)"
+	CFLAGS_FOR_TARGET="$(call ptx/toolchain-cross-debug-flags, CROSS_GCC) -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" \
+	CXXFLAGS_FOR_TARGET="$(call ptx/toolchain-cross-debug-flags, CROSS_GCC) -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64"
 
 #   --enable-tls            enable or disable generation of tls code
 #                           overriding the assembler check for tls support
---------------------------------------------------------------------------

Regards,
Michael

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886

-- 
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 |