[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #14 from Andrew Pinski --- Dup of bug 78017 for new enough glibc (which is all of ones that support time64_t IIRC). *** This bug has been marked as a duplicate of bug 78017 ***
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 Florian Weimer changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103133 CC||fw at gcc dot gnu.org --- Comment #13 from Florian Weimer --- (In reply to Jonathan Wakely from comment #11) > (In reply to Jonathan Wakely from comment #10) > > If you have glibc 2.34 then you can use -DGTHREAD_USE_WEAK=0 to disable the > > weak refs in gthr-posix.h > > I think that is indeed the correct fix, as you originally asked about. But > only for glibc 2.34 and later. Only glibc 2.34 and later have this problem because previous upstream versions lack dual-API time64 support. I would like to claim that we did this deliberately, but the version alignment between libpthread removal and the new time64 support was a bit of a coincidence.
Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
On Fri, May 05, 2023 at 01:13:50PM +0200, Florian Weimer via Gcc-bugs wrote: > * Puneet Kumar Yatnal via Gcc-bugs: > > > What is next step here? How do I post this in Bugzilla and get > > support. > > This issue has already been fixed with this commit: > > commit 80fe172ba9820199c2bbce5d0611ffca27823049 > Author: Jonathan Wakely > Date: Tue Nov 9 23:45:36 2021 + > > libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133] > > Since Glibc 2.34 all pthreads symbols are defined directly in libc not > libpthread, and since Glibc 2.32 we have used __libc_single_threaded to > avoid unnecessary locking in single-threaded programs. This means there > is no reason to avoid linking to libpthread now, and so no reason to use > weak symbols defined in gthr-posix.h for all the pthread_xxx functions. > > libstdc++-v3/ChangeLog: > > PR libstdc++/100748 > PR libstdc++/103133 > * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK): > Define for glibc 2.34 and later. > > It's been backported to GCC 10, but not GCC 9. Backporting to 9 > requires some messaging to get into 9 which lacks commit > b11c74b0e357652a1f1f0d93 ("libstdc++: Avoid calling undefined > __gthread_self weak symbol [PR 95989]"). GCC 9 is not supported anymore, so backporting anything to it (at least upstream) is not possible. Jakub
Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
On Fri, 5 May 2023 at 12:13, Florian Weimer wrote: > > * Puneet Kumar Yatnal via Gcc-bugs: > > > What is next step here? How do I post this in Bugzilla and get > > support. > > This issue has already been fixed with this commit: > > commit 80fe172ba9820199c2bbce5d0611ffca27823049 > Author: Jonathan Wakely > Date: Tue Nov 9 23:45:36 2021 + > > libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133] Indeed, as pointed out in bugzilla after the discussion moved there: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 > > Since Glibc 2.34 all pthreads symbols are defined directly in libc not > libpthread, and since Glibc 2.32 we have used __libc_single_threaded to > avoid unnecessary locking in single-threaded programs. This means there > is no reason to avoid linking to libpthread now, and so no reason to use > weak symbols defined in gthr-posix.h for all the pthread_xxx functions. > > libstdc++-v3/ChangeLog: > > PR libstdc++/100748 > PR libstdc++/103133 > * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK): > Define for glibc 2.34 and later. > > It's been backported to GCC 10, but not GCC 9. Backporting to 9 > requires some messaging to get into 9 which lacks commit > b11c74b0e357652a1f1f0d93 ("libstdc++: Avoid calling undefined > __gthread_self weak symbol [PR 95989]"). > > Thanks, > Florian >
Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
* Puneet Kumar Yatnal via Gcc-bugs: > What is next step here? How do I post this in Bugzilla and get > support. This issue has already been fixed with this commit: commit 80fe172ba9820199c2bbce5d0611ffca27823049 Author: Jonathan Wakely Date: Tue Nov 9 23:45:36 2021 + libstdc++: Disable gthreads weak symbols for glibc 2.34 [PR103133] Since Glibc 2.34 all pthreads symbols are defined directly in libc not libpthread, and since Glibc 2.32 we have used __libc_single_threaded to avoid unnecessary locking in single-threaded programs. This means there is no reason to avoid linking to libpthread now, and so no reason to use weak symbols defined in gthr-posix.h for all the pthread_xxx functions. libstdc++-v3/ChangeLog: PR libstdc++/100748 PR libstdc++/103133 * config/os/gnu-linux/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK): Define for glibc 2.34 and later. It's been backported to GCC 10, but not GCC 9. Backporting to 9 requires some messaging to get into 9 which lacks commit b11c74b0e357652a1f1f0d93 ("libstdc++: Avoid calling undefined __gthread_self weak symbol [PR 95989]"). Thanks, Florian
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #12 from Puneet B --- Thanks for update , since we are using gcc-2.34 , this need to picked as fix. but do you seen any side impact of this fix which need to be validated?
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #11 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #10) > If you have glibc 2.34 then you can use -DGTHREAD_USE_WEAK=0 to disable the > weak refs in gthr-posix.h I think that is indeed the correct fix, as you originally asked about. But only for glibc 2.34 and later.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #10 from Jonathan Wakely --- Ah, it works for C++ because of r12-5108-g80fe172ba98201 With a recent glibc __gthread_cond_timedwait just calls pthread_cond_timedwait directly, so use correctly redirected to __pthread_cond_timedwait64. If you have glibc 2.34 then you can use -DGTHREAD_USE_WEAK=0 to disable the weak refs in gthr-posix.h
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2023-04-20 --- Comment #9 from Jonathan Wakely --- It works correctly with 10.4.1 and 11.3.0 and 12.1.0 so it looks like this isn't true: (In reply to Puneet B from comment #3) > It can be reproduceable in gcc master branch or latest release..dont look at > it as GCC particular version bug. You haven't provided a testcase though, so we don't know what you're seeing.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #8 from Puneet B --- could some one provide some pointers here? if its observed in gcc.9.3.0 and fixed in latest GCC, please point me the same, i will pick and validate quickly
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #7 from Puneet B --- Any pointers here help to debug further.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #6 from Puneet B --- its not after refer the wiki, its observed on target where its clear that even after compiling application with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 its still calling ___pthread_cond_timedwait More over if i call pthread_cond_timedwait directly its calling __pthread_cond_timedwait64 directly as i already mentioned in this thread. And issue is resolved if i add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h it clears that weakref symbol is not working properly during linker stage. both __gthrw_(pthread_cond_timedwait) and pthread_cond_timedwait are expected to invoke same API. let me know if you need any more inputs
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- 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 *__mutex, 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=64 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 symbol of that name, rather than to __pthread_cond_timedwait64, so we end up passing 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) 13__gthread_cond_timedwait(, , ); (gdb) step __gthread_cond_timedwait (__cond=0x804c060 , __mutex=0x804c090 , __abs_timeout=0xc7e8) 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) ___pthread_cond_timedwait (cond=0x804c060 , mutex=0x804c090 , abstime=0xc7e8) 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 = valid_timespec_to_timespec64 (*abstime); 657 658 return __pthread_cond_timedwait64 (cond, mutex, ); 659 } If I recompile the same code with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 then the call to __gthread_cond_timedwait resolves to glibc's __pthread_cond_timedwait64: (gdb) 13__gthread_cond_timedwait(, , ); (gdb) step __gthread_cond_timedwait (__cond=0x804c060 , __mutex=0x804c090 , __abs_timeout=0xc7e0) 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) ___pthread_cond_timedwait64 (cond=0x804c060 , mutex=0x804c090 , abstime=0xc7e0) 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?
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #4 from Jonathan Wakely --- Yes, I know. I'm just pointing out that you're reporting a bug against an unsupported version.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #3 from Puneet B --- It can be reproduceable in gcc master branch or latest release..dont look at it as GCC particular version bug.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #2 from Jonathan Wakely --- N.B. GCC 9 is no longer supported, so any changes will not help that version.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #1 from Puneet B --- Here issue is weakref symbol in gcc not using the __asm_ function pointed by pthread.h instead its calling directly ___pthread_cond_timedwait which is exposed by version_symbol in pthread_cond_wait.c of glibc
[Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 Bug ID: 109540 Summary: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: punitb20 at gmail dot com Target Milestone: --- All if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for Y2038 fix(where all timer related variable moved to 64 bit instead of 32 bit ), pthread_cond_timedwait function from gthr_posix.h is calling different function in pthrea_cond_wait.c of glibc(due to weakref of symbol pthread_cond_timedwait()) which impacting the time value. >From pthread.h extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond, pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict __abstime) __asm__ ("" "__pthread_cond_timedwait64") >From gthread_posix.h: static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait __attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__ (pthread_cond_timedwait))); __gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait invoking in glibc instead of __pthread_cond_timedwait64 which is impacting time value as __pthread_cond_timedwait is converting value from 32 bit to 64 bit. normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly and its working fine. From: pthread_cond_wait.c #if __TIMESIZE == 64 strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait) #else strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64) libc_hidden_def (__pthread_cond_timedwait64) int ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime) { struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime); return __pthread_cond_timedwait64 (cond, mutex, ); } #endif /* __TIMESIZE == 64 */ versioned_symbol (libc, ___pthread_cond_timedwait, pthread_cond_timedwait, GLIBC_2_3_2); libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait) #ifndef SHARED strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait) #endif if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is resolved but that is not correct way as it disable weakref for all symbol, please let me know what is correct way to fix this, this i observed with gcc-9.3.0 gcc and glibc 2.34 Regards Puneet
RE: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
What is next step here? How do I post this in Bugzilla and get support. Regards Puneet From: Jonathan Wakely Sent: Monday, April 17, 2023 1:06 PM To: Puneet Kumar Yatnal (QUIC) Cc: Andrew Pinski ; gcc-help ; gcc-bugs@gcc.gnu.org Subject: Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values On Mon, 17 Apr 2023, 09:27 Puneet Kumar Yatnal (QUIC), mailto:quic_pune...@quicinc.com>> wrote: Here issue is weakref symbol in gcc not using the __asm_ function pointed by pthread.h instead its calling directly ___pthread_cond_timedwait which is exposed by version_symbol in pthread_cond_wait.c of glibc Yes, I understand that. Like Andrew said, please file it in bugzilla. Somebody will create your account later today. From: Jonathan Wakely mailto:jwakely@gmail.com>> Sent: Monday, April 17, 2023 12:53 PM To: Andrew Pinski mailto:pins...@gmail.com>> Cc: Puneet Kumar Yatnal (QUIC) mailto:quic_pune...@quicinc.com>>; gcc-help mailto:gcc-h...@gcc.gnu.org>>; gcc-bugs@gcc.gnu.org<mailto:gcc-bugs@gcc.gnu.org> Subject: Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. On Mon, 17 Apr 2023, 07:54 Andrew Pinski via Gcc-help, mailto:gcc-h...@gcc.gnu.org>> wrote: On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via Gcc-bugs mailto:gcc-bugs@gcc.gnu.org>> wrote: > > > ++ > From: Puneet Kumar Yatnal (QUIC) > Sent: Monday, April 17, 2023 9:26 AM > To: gcc-h...@gcc.gnu.org<mailto:gcc-h...@gcc.gnu.org> > Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has impact > on time values First gcc-bugs@ is not the right place to report a bug report as gcc-bugs is mainly for automated emails from bugzilla. Please use bugzilla first. > > All > > if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for > Y2038 fix(where all timer related variable moved to 64 bit instead of 32 bit > ), pthread_cond_timedwait function from gthr_posix.h is calling different > function in pthrea_cond_wait.c of glibc(due to weakref of symbol > pthread_cond_timedwait()) which impacting the time value. Note libstdc++ does ABI changes too which is NOT part of that ABI design. This is where the symbol __gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So any changes you might do to fix __gthrw_pthread_cond_timedwait is not really going to work without wider ABI fixes to libstdc++. I don't know any one who is making those changes/fixes. So you should file an bug requesting it. And maybe even have a design document ready for it. There are many/some classes which have timespec inside them I don't think that's true. We don't use timespec members, they're just local variables, and very occasionally function parameters. and not just the mutex related ones. Thanks, Andrew > > From pthread.h > extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond, > pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict > __abstime) __asm__ ("" "__pthread_cond_timedwait64") > > From gthread_posix.h: > static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait > __attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__ > (pthread_cond_timedwait))); > > > __gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait invoking in > glibc instead of __pthread_cond_timedwait64 which is impacting time value > as __pthread_cond_timedwait is converting value from 32 bit to 64 bit. > > normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly > and its working fine. > > From: pthread_cond_wait.c > > #if __TIMESIZE == 64 > strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait) > #else > strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64) > libc_hidden_def (__pthread_cond_timedwait64) > > int > ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex, > const struct timespec *abstime) > { > struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime); > > return __pthread_cond_timedwait64 (cond, mutex, ); > } > #endif /* __TIMESIZE == 64 */ > versioned_symbol (libc, ___pthread_cond_timedwait, > pthread_cond_timedwait, GLIBC_2_3_2); > libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait) > #ifndef SHARED > strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait) > #endif > > if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is resolved > but that is not correct way as it disable weakref for all symbol, please let > me know what is correct way to fix this, this i observed with gcc-9.3.0 gcc > and glibc 2.34 > > Regards > Puneet >
Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
On Mon, 17 Apr 2023, 09:27 Puneet Kumar Yatnal (QUIC), < quic_pune...@quicinc.com> wrote: > Here issue is weakref symbol in gcc not using the __asm_ function pointed > by pthread.h instead its calling directly ___pthread_cond_timedwait which > is exposed by version_symbol in pthread_cond_wait.c of glibc > Yes, I understand that. Like Andrew said, please file it in bugzilla. Somebody will create your account later today. > > *From:* Jonathan Wakely > *Sent:* Monday, April 17, 2023 12:53 PM > *To:* Andrew Pinski > *Cc:* Puneet Kumar Yatnal (QUIC) ; gcc-help < > gcc-h...@gcc.gnu.org>; gcc-bugs@gcc.gnu.org > *Subject:* Re: Y2038: GCC gthr-posix.h weakref symbol invoking function > has impact on time values > > > > *WARNING:* This email originated from outside of Qualcomm. Please be wary > of any links or attachments, and do not enable macros. > > > > On Mon, 17 Apr 2023, 07:54 Andrew Pinski via Gcc-help, < > gcc-h...@gcc.gnu.org> wrote: > > On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via > Gcc-bugs wrote: > > > > > > ++ > > From: Puneet Kumar Yatnal (QUIC) > > Sent: Monday, April 17, 2023 9:26 AM > > To: gcc-h...@gcc.gnu.org > > Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has > impact on time values > > First gcc-bugs@ is not the right place to report a bug report as > gcc-bugs is mainly for automated emails from bugzilla. Please use > bugzilla first. > > > > > All > > > > if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign > for Y2038 fix(where all timer related variable moved to 64 bit instead of > 32 bit ), pthread_cond_timedwait function from gthr_posix.h is calling > different function in pthrea_cond_wait.c of glibc(due to weakref of symbol > pthread_cond_timedwait()) which impacting the time value. > > Note libstdc++ does ABI changes too which is NOT part of that ABI design. > This is where the symbol > __gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So > any changes you might do to fix __gthrw_pthread_cond_timedwait is not > really going to work without wider ABI fixes to libstdc++. > I don't know any one who is making those changes/fixes. So you should > file an bug requesting it. And maybe even have a design document ready > for it. There are many/some classes which have timespec inside them > > > > I don't think that's true. We don't use timespec members, they're just > local variables, and very occasionally function parameters. > > > > > > > > and not just the mutex related ones. > > Thanks, > Andrew > > > > > From pthread.h > > extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond, > pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict > __abstime) __asm__ ("" "__pthread_cond_timedwait64") > > > > From gthread_posix.h: > > static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait > __attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__ > (pthread_cond_timedwait))); > > > > > > __gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait > invoking in glibc instead of __pthread_cond_timedwait64 which is > impacting time value as __pthread_cond_timedwait is converting value from > 32 bit to 64 bit. > > > > normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 > properly and its working fine. > > > > From: pthread_cond_wait.c > > > > #if __TIMESIZE == 64 > > strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait) > > #else > > strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64) > > libc_hidden_def (__pthread_cond_timedwait64) > > > > int > > ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex, > > const struct timespec *abstime) > > { > > struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime); > > > > return __pthread_cond_timedwait64 (cond, mutex, ); > > } > > #endif /* __TIMESIZE == 64 */ > > versioned_symbol (libc, ___pthread_cond_timedwait, > > pthread_cond_timedwait, GLIBC_2_3_2); > > libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait) > > #ifndef SHARED > > strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait) > > #endif > > > > if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is > resolved but that is not correct way as it disable weakref for all symbol, > please let me know what is correct way to fix this, this i observed with > gcc-9.3.0 gcc and glibc 2.34 > > > > Regards > > Puneet > > > >
RE: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
Here issue is weakref symbol in gcc not using the __asm_ function pointed by pthread.h instead its calling directly ___pthread_cond_timedwait which is exposed by version_symbol in pthread_cond_wait.c of glibc From: Jonathan Wakely Sent: Monday, April 17, 2023 12:53 PM To: Andrew Pinski Cc: Puneet Kumar Yatnal (QUIC) ; gcc-help ; gcc-bugs@gcc.gnu.org Subject: Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. On Mon, 17 Apr 2023, 07:54 Andrew Pinski via Gcc-help, mailto:gcc-h...@gcc.gnu.org>> wrote: On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via Gcc-bugs mailto:gcc-bugs@gcc.gnu.org>> wrote: > > > ++ > From: Puneet Kumar Yatnal (QUIC) > Sent: Monday, April 17, 2023 9:26 AM > To: gcc-h...@gcc.gnu.org<mailto:gcc-h...@gcc.gnu.org> > Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has impact > on time values First gcc-bugs@ is not the right place to report a bug report as gcc-bugs is mainly for automated emails from bugzilla. Please use bugzilla first. > > All > > if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for > Y2038 fix(where all timer related variable moved to 64 bit instead of 32 bit > ), pthread_cond_timedwait function from gthr_posix.h is calling different > function in pthrea_cond_wait.c of glibc(due to weakref of symbol > pthread_cond_timedwait()) which impacting the time value. Note libstdc++ does ABI changes too which is NOT part of that ABI design. This is where the symbol __gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So any changes you might do to fix __gthrw_pthread_cond_timedwait is not really going to work without wider ABI fixes to libstdc++. I don't know any one who is making those changes/fixes. So you should file an bug requesting it. And maybe even have a design document ready for it. There are many/some classes which have timespec inside them I don't think that's true. We don't use timespec members, they're just local variables, and very occasionally function parameters. and not just the mutex related ones. Thanks, Andrew > > From pthread.h > extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond, > pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict > __abstime) __asm__ ("" "__pthread_cond_timedwait64") > > From gthread_posix.h: > static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait > __attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__ > (pthread_cond_timedwait))); > > > __gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait invoking in > glibc instead of __pthread_cond_timedwait64 which is impacting time value > as __pthread_cond_timedwait is converting value from 32 bit to 64 bit. > > normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly > and its working fine. > > From: pthread_cond_wait.c > > #if __TIMESIZE == 64 > strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait) > #else > strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64) > libc_hidden_def (__pthread_cond_timedwait64) > > int > ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex, > const struct timespec *abstime) > { > struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime); > > return __pthread_cond_timedwait64 (cond, mutex, ); > } > #endif /* __TIMESIZE == 64 */ > versioned_symbol (libc, ___pthread_cond_timedwait, > pthread_cond_timedwait, GLIBC_2_3_2); > libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait) > #ifndef SHARED > strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait) > #endif > > if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is resolved > but that is not correct way as it disable weakref for all symbol, please let > me know what is correct way to fix this, this i observed with gcc-9.3.0 gcc > and glibc 2.34 > > Regards > Puneet >
Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
On Mon, 17 Apr 2023, 07:54 Andrew Pinski via Gcc-help, wrote: > On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via > Gcc-bugs wrote: > > > > > > ++ > > From: Puneet Kumar Yatnal (QUIC) > > Sent: Monday, April 17, 2023 9:26 AM > > To: gcc-h...@gcc.gnu.org > > Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has > impact on time values > > First gcc-bugs@ is not the right place to report a bug report as > gcc-bugs is mainly for automated emails from bugzilla. Please use > bugzilla first. > > > > > All > > > > if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign > for Y2038 fix(where all timer related variable moved to 64 bit instead of > 32 bit ), pthread_cond_timedwait function from gthr_posix.h is calling > different function in pthrea_cond_wait.c of glibc(due to weakref of symbol > pthread_cond_timedwait()) which impacting the time value. > > Note libstdc++ does ABI changes too which is NOT part of that ABI design. > This is where the symbol > __gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So > any changes you might do to fix __gthrw_pthread_cond_timedwait is not > really going to work without wider ABI fixes to libstdc++. > I don't know any one who is making those changes/fixes. So you should > file an bug requesting it. And maybe even have a design document ready > for it. There are many/some classes which have timespec inside them I don't think that's true. We don't use timespec members, they're just local variables, and very occasionally function parameters. and not just the mutex related ones. > > Thanks, > Andrew > > > > > From pthread.h > > extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond, > pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict > __abstime) __asm__ ("" "__pthread_cond_timedwait64") > > > > From gthread_posix.h: > > static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait > __attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__ > (pthread_cond_timedwait))); > > > > > > __gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait > invoking in glibc instead of __pthread_cond_timedwait64 which is > impacting time value as __pthread_cond_timedwait is converting value from > 32 bit to 64 bit. > > > > normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 > properly and its working fine. > > > > From: pthread_cond_wait.c > > > > #if __TIMESIZE == 64 > > strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait) > > #else > > strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64) > > libc_hidden_def (__pthread_cond_timedwait64) > > > > int > > ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex, > > const struct timespec *abstime) > > { > > struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime); > > > > return __pthread_cond_timedwait64 (cond, mutex, ); > > } > > #endif /* __TIMESIZE == 64 */ > > versioned_symbol (libc, ___pthread_cond_timedwait, > > pthread_cond_timedwait, GLIBC_2_3_2); > > libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait) > > #ifndef SHARED > > strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait) > > #endif > > > > if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is > resolved but that is not correct way as it disable weakref for all symbol, > please let me know what is correct way to fix this, this i observed with > gcc-9.3.0 gcc and glibc 2.34 > > > > Regards > > Puneet > > >
RE: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
Hi @Andrew Pinski >Note libstdc++ does ABI changes too which is NOT part of that ABI design. >This is where the symbol >__gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So any >changes you might do to fix __gthrw_pthread_cond_timedwait is not really going >to work >without wider ABI fixes to libstdc++. >I don't know any one who is making those changes/fixes. So you should file an >bug requesting it. And maybe even have a design document ready for it. There >are many/some >classes which have timespec inside them and not just the mutex >related ones. Are you saying the fix need to add in libstdc++ abi changes? If yes could you please tell how to request that? What is file which has all libstdc++ abi changes? I don’t have design document of any such, this need to be fixed as its bug identified in 32 bit system which uses 64 timer values. Regards Puneet -Original Message- From: Andrew Pinski Sent: Monday, April 17, 2023 11:24 AM To: Puneet Kumar Yatnal (QUIC) Cc: gcc-h...@gcc.gnu.org; gcc-bugs@gcc.gnu.org Subject: Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via Gcc-bugs wrote: > > > ++ > From: Puneet Kumar Yatnal (QUIC) > Sent: Monday, April 17, 2023 9:26 AM > To: gcc-h...@gcc.gnu.org > Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has > impact on time values First gcc-bugs@ is not the right place to report a bug report as gcc-bugs is mainly for automated emails from bugzilla. Please use bugzilla first. > > All > > if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for > Y2038 fix(where all timer related variable moved to 64 bit instead of 32 bit > ), pthread_cond_timedwait function from gthr_posix.h is calling different > function in pthrea_cond_wait.c of glibc(due to weakref of symbol > pthread_cond_timedwait()) which impacting the time value. Note libstdc++ does ABI changes too which is NOT part of that ABI design. This is where the symbol __gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So any changes you might do to fix __gthrw_pthread_cond_timedwait is not really going to work without wider ABI fixes to libstdc++. I don't know any one who is making those changes/fixes. So you should file an bug requesting it. And maybe even have a design document ready for it. There are many/some classes which have timespec inside them and not just the mutex related ones. Thanks, Andrew > > From pthread.h > extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond, > pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict > __abstime) __asm__ ("" "__pthread_cond_timedwait64") > > From gthread_posix.h: > static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait > __attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__ > (pthread_cond_timedwait))); > > > __gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait invoking in > glibc instead of __pthread_cond_timedwait64 which is impacting time value > as __pthread_cond_timedwait is converting value from 32 bit to 64 bit. > > normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly > and its working fine. > > From: pthread_cond_wait.c > > #if __TIMESIZE == 64 > strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait) > #else strong_alias (___pthread_cond_timedwait64, > __pthread_cond_timedwait64) libc_hidden_def > (__pthread_cond_timedwait64) > > int > ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex, > const struct timespec *abstime) { > struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime); > > return __pthread_cond_timedwait64 (cond, mutex, ); } #endif /* > __TIMESIZE == 64 */ versioned_symbol (libc, ___pthread_cond_timedwait, > pthread_cond_timedwait, GLIBC_2_3_2); > libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait) > #ifndef SHARED strong_alias (___pthread_cond_timedwait, > __pthread_cond_timedwait) #endif > > if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is resolved > but that is not correct way as it disable weakref for all symbol, please let > me know what is correct way to fix this, this i observed with gcc-9.3.0 gcc > and glibc 2.34 > > Regards > Puneet >
Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via Gcc-bugs wrote: > > > ++ > From: Puneet Kumar Yatnal (QUIC) > Sent: Monday, April 17, 2023 9:26 AM > To: gcc-h...@gcc.gnu.org > Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has impact > on time values First gcc-bugs@ is not the right place to report a bug report as gcc-bugs is mainly for automated emails from bugzilla. Please use bugzilla first. > > All > > if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for > Y2038 fix(where all timer related variable moved to 64 bit instead of 32 bit > ), pthread_cond_timedwait function from gthr_posix.h is calling different > function in pthrea_cond_wait.c of glibc(due to weakref of symbol > pthread_cond_timedwait()) which impacting the time value. Note libstdc++ does ABI changes too which is NOT part of that ABI design. This is where the symbol __gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So any changes you might do to fix __gthrw_pthread_cond_timedwait is not really going to work without wider ABI fixes to libstdc++. I don't know any one who is making those changes/fixes. So you should file an bug requesting it. And maybe even have a design document ready for it. There are many/some classes which have timespec inside them and not just the mutex related ones. Thanks, Andrew > > From pthread.h > extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond, > pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict > __abstime) __asm__ ("" "__pthread_cond_timedwait64") > > From gthread_posix.h: > static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait > __attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__ > (pthread_cond_timedwait))); > > > __gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait invoking in > glibc instead of __pthread_cond_timedwait64 which is impacting time value > as __pthread_cond_timedwait is converting value from 32 bit to 64 bit. > > normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly > and its working fine. > > From: pthread_cond_wait.c > > #if __TIMESIZE == 64 > strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait) > #else > strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64) > libc_hidden_def (__pthread_cond_timedwait64) > > int > ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex, > const struct timespec *abstime) > { > struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime); > > return __pthread_cond_timedwait64 (cond, mutex, ); > } > #endif /* __TIMESIZE == 64 */ > versioned_symbol (libc, ___pthread_cond_timedwait, > pthread_cond_timedwait, GLIBC_2_3_2); > libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait) > #ifndef SHARED > strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait) > #endif > > if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is resolved > but that is not correct way as it disable weakref for all symbol, please let > me know what is correct way to fix this, this i observed with gcc-9.3.0 gcc > and glibc 2.34 > > Regards > Puneet >
RE: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
++ From: Puneet Kumar Yatnal (QUIC) Sent: Monday, April 17, 2023 9:26 AM To: gcc-h...@gcc.gnu.org Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has impact on time values All if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for Y2038 fix(where all timer related variable moved to 64 bit instead of 32 bit ), pthread_cond_timedwait function from gthr_posix.h is calling different function in pthrea_cond_wait.c of glibc(due to weakref of symbol pthread_cond_timedwait()) which impacting the time value. >From pthread.h extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond, pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict __abstime) __asm__ ("" "__pthread_cond_timedwait64") >From gthread_posix.h: static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait __attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__ (pthread_cond_timedwait))); __gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait invoking in glibc instead of __pthread_cond_timedwait64 which is impacting time value as __pthread_cond_timedwait is converting value from 32 bit to 64 bit. normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly and its working fine. From: pthread_cond_wait.c #if __TIMESIZE == 64 strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait) #else strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64) libc_hidden_def (__pthread_cond_timedwait64) int ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime) { struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime); return __pthread_cond_timedwait64 (cond, mutex, ); } #endif /* __TIMESIZE == 64 */ versioned_symbol (libc, ___pthread_cond_timedwait, pthread_cond_timedwait, GLIBC_2_3_2); libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait) #ifndef SHARED strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait) #endif if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is resolved but that is not correct way as it disable weakref for all symbol, please let me know what is correct way to fix this, this i observed with gcc-9.3.0 gcc and glibc 2.34 Regards Puneet