From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A239F3858D1E; Tue, 18 Apr 2023 11:19:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A239F3858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1681816763; bh=9O51PYYTYiirEZyAx96FpSYHij8WDI9t7ebsv6dV8Tg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dlppJZ278eksqC9ON6UsOFmQOGM+q7wMcBIlPwbfif6HxxU9j2D5XfiA6JFl3Qkgd FiPJ5PFyWZ5aJTq0oTdndT6IR3iPicRx3YrRtCYuTYlaiyZgR3McZUMtTUY8ulvITT e9DQWrW+HT+oU+Ow+zKSh82lLcNi6EGsCgEuZP0Q= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values Date: Tue, 18 Apr 2023 11:19:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libgcc X-Bugzilla-Version: 9.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109540 --- Comment #5 from Jonathan Wakely --- The description is a bit confusing, but the issue is that we define: typedef struct timespec __gthread_time_t; and then use that in several functions like this: static inline int __gthread_cond_timedwait (__gthread_cond_t *__cond, __gthread_mutex_t *__mu= tex, const __gthread_time_t *__abs_timeout) { return __gthrw_(pthread_cond_timedwait) (__cond, __mutex, __abs_timeout); } If libc uses a 64-bit time_t in struct timespec then we need to use __pthread_cond_timedwait64 instead of pthread_cond_timedwait, because the latter expects a struct containing a 32-bit time_t instead of a 64-bit one. The weak alias referenced by __gthrw_ is defined like so: static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait __attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__ (pthread_cond_timedwait))); Where the _TIME_BITS=3D64 declaration of pthread_cond_timedwait is: extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond, pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict __abstime) __asm__ ("" "__pthread_cond_timedwait64") The reported issue is that weakref("pthread_cond_timedwait") binds to a sym= bol of that name, rather than to __pthread_cond_timedwait64, so we end up passi= ng a 64-bit timespec to the 32-bit pthread_cond_timedwait. However, that's not what I observe when I test it. If I compile with 32-bit time_t for i686 using GCC 12 and glibc-2.36-9.fc37.i686 then a call to __gthread_cond_timedwait will resolve= to glibc's pthread_cond_timedwait which expects a 32-bit timespec: (gdb)=20 13 __gthread_cond_timedwait(&cond, &mutex, &ts); (gdb) step __gthread_cond_timedwait (__cond=3D0x804c060 , __mutex=3D0x804c090 , __abs_timeout=3D0xffffc7e8) at /usr/include/c++/12/x86_64-redhat-linux/32/bits/gthr-default.h:872 872 return __gthrw_(pthread_cond_timedwait) (__cond, __mutex, __abs_timeout); (gdb)=20 ___pthread_cond_timedwait (cond=3D0x804c060 , mutex=3D0x804c090 , abstime=3D0xffffc7e8) at pthread_cond_wait.c:655 655 { (gdb) l 650 libc_hidden_def (__pthread_cond_timedwait64) 651 652 int 653 ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex, 654 const struct timespec *abstime) 655 { 656 struct __timespec64 ts64 =3D valid_timespec_to_timespec64 (*absti= me); 657 658 return __pthread_cond_timedwait64 (cond, mutex, &ts64); 659 } If I recompile the same code with -D_TIME_BITS=3D64 -D_FILE_OFFSET_BITS=3D6= 4 then the call to __gthread_cond_timedwait resolves to glibc's __pthread_cond_timedwait64: (gdb)=20 13 __gthread_cond_timedwait(&cond, &mutex, &ts); (gdb) step __gthread_cond_timedwait (__cond=3D0x804c060 , __mutex=3D0x804c090 , __abs_timeout=3D0xffffc7e0) at /usr/include/c++/12/x86_64-redhat-linux/32/bits/gthr-default.h:872 872 return __gthrw_(pthread_cond_timedwait) (__cond, __mutex, __abs_timeout); (gdb)=20 ___pthread_cond_timedwait64 (cond=3D0x804c060 , mutex=3D0x804c090 , abstime=3D0xffffc7e0) at pthread_cond_wait.c:632 632 { (gdb) l 627 628 /* See __pthread_cond_wait_common. */ 629 int 630 ___pthread_cond_timedwait64 (pthread_cond_t *cond, pthread_mutex_t *mutex, 631 const struct __timespec64 *abstime) 632 { 633 /* Check parameter validity. This should also tell the compiler = that 634 it can assume that abstime is not NULL. */ 635 if (! valid_nanoseconds (abstime->tv_nsec)) 636 return EINVAL; So it seems to work fine. Do you actually observe a bug, or are you just speculating from reading the wiki page and headers?=