public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* RE: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values [not found] <DM8PR02MB7863C7021B8B36DAF9084509949C9@DM8PR02MB7863.namprd02.prod.outlook.com> @ 2023-04-17 5:40 ` Puneet Kumar Yatnal (QUIC) 2023-04-17 5:53 ` Andrew Pinski 0 siblings, 1 reply; 10+ messages in thread From: Puneet Kumar Yatnal (QUIC) @ 2023-04-17 5:40 UTC (permalink / raw) To: Puneet Kumar Yatnal (QUIC), gcc-help, gcc-bugs [-- Attachment #1: Type: text/plain, Size: 2392 bytes --] ++ From: Puneet Kumar Yatnal (QUIC) Sent: Monday, April 17, 2023 9:26 AM To: gcc-help@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, &ts64); } #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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values 2023-04-17 5:40 ` Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values Puneet Kumar Yatnal (QUIC) @ 2023-04-17 5:53 ` Andrew Pinski 2023-04-17 6:09 ` Puneet Kumar Yatnal 2023-04-17 7:22 ` Jonathan Wakely 0 siblings, 2 replies; 10+ messages in thread From: Andrew Pinski @ 2023-04-17 5:53 UTC (permalink / raw) To: Puneet Kumar Yatnal (QUIC); +Cc: gcc-help, gcc-bugs On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via Gcc-bugs <gcc-bugs@gcc.gnu.org> wrote: > > > ++ > From: Puneet Kumar Yatnal (QUIC) > Sent: Monday, April 17, 2023 9:26 AM > To: gcc-help@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, &ts64); > } > #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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values 2023-04-17 5:53 ` Andrew Pinski @ 2023-04-17 6:09 ` Puneet Kumar Yatnal 2023-04-17 7:22 ` Jonathan Wakely 1 sibling, 0 replies; 10+ messages in thread From: Puneet Kumar Yatnal @ 2023-04-17 6:09 UTC (permalink / raw) To: Andrew Pinski, Puneet Kumar Yatnal (QUIC); +Cc: gcc-help, gcc-bugs 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 <pinskia@gmail.com> Sent: Monday, April 17, 2023 11:24 AM To: Puneet Kumar Yatnal (QUIC) <quic_puneety@quicinc.com> Cc: gcc-help@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 <gcc-bugs@gcc.gnu.org> wrote: > > > ++ > From: Puneet Kumar Yatnal (QUIC) > Sent: Monday, April 17, 2023 9:26 AM > To: gcc-help@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, &ts64); } #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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values 2023-04-17 5:53 ` Andrew Pinski 2023-04-17 6:09 ` Puneet Kumar Yatnal @ 2023-04-17 7:22 ` Jonathan Wakely 2023-04-17 7:27 ` Puneet Kumar Yatnal (QUIC) 1 sibling, 1 reply; 10+ messages in thread From: Jonathan Wakely @ 2023-04-17 7:22 UTC (permalink / raw) To: Andrew Pinski; +Cc: Puneet Kumar Yatnal (QUIC), gcc-help, gcc-bugs [-- Attachment #1: Type: text/plain, Size: 3738 bytes --] On Mon, 17 Apr 2023, 07:54 Andrew Pinski via Gcc-help, <gcc-help@gcc.gnu.org> wrote: > On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via > Gcc-bugs <gcc-bugs@gcc.gnu.org> wrote: > > > > > > ++ > > From: Puneet Kumar Yatnal (QUIC) > > Sent: Monday, April 17, 2023 9:26 AM > > To: gcc-help@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, &ts64); > > } > > #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 > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values 2023-04-17 7:22 ` Jonathan Wakely @ 2023-04-17 7:27 ` Puneet Kumar Yatnal (QUIC) 2023-04-17 7:35 ` Jonathan Wakely 0 siblings, 1 reply; 10+ messages in thread From: Puneet Kumar Yatnal (QUIC) @ 2023-04-17 7:27 UTC (permalink / raw) To: Jonathan Wakely, Andrew Pinski Cc: Puneet Kumar Yatnal (QUIC), gcc-help, gcc-bugs [-- Attachment #1: Type: text/plain, Size: 4315 bytes --] 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 <jwakely.gcc@gmail.com> Sent: Monday, April 17, 2023 12:53 PM To: Andrew Pinski <pinskia@gmail.com> Cc: Puneet Kumar Yatnal (QUIC) <quic_puneety@quicinc.com>; gcc-help <gcc-help@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-help@gcc.gnu.org<mailto:gcc-help@gcc.gnu.org>> wrote: On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via Gcc-bugs <gcc-bugs@gcc.gnu.org<mailto:gcc-bugs@gcc.gnu.org>> wrote: > > > ++ > From: Puneet Kumar Yatnal (QUIC) > Sent: Monday, April 17, 2023 9:26 AM > To: gcc-help@gcc.gnu.org<mailto:gcc-help@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, &ts64); > } > #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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values 2023-04-17 7:27 ` Puneet Kumar Yatnal (QUIC) @ 2023-04-17 7:35 ` Jonathan Wakely 2023-04-18 2:53 ` Puneet Kumar Yatnal (QUIC) 0 siblings, 1 reply; 10+ messages in thread From: Jonathan Wakely @ 2023-04-17 7:35 UTC (permalink / raw) To: Puneet Kumar Yatnal (QUIC); +Cc: Andrew Pinski, gcc-help, gcc-bugs [-- Attachment #1: Type: text/plain, Size: 4739 bytes --] On Mon, 17 Apr 2023, 09:27 Puneet Kumar Yatnal (QUIC), < quic_puneety@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 <jwakely.gcc@gmail.com> > *Sent:* Monday, April 17, 2023 12:53 PM > *To:* Andrew Pinski <pinskia@gmail.com> > *Cc:* Puneet Kumar Yatnal (QUIC) <quic_puneety@quicinc.com>; gcc-help < > gcc-help@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-help@gcc.gnu.org> wrote: > > On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via > Gcc-bugs <gcc-bugs@gcc.gnu.org> wrote: > > > > > > ++ > > From: Puneet Kumar Yatnal (QUIC) > > Sent: Monday, April 17, 2023 9:26 AM > > To: gcc-help@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, &ts64); > > } > > #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 > > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values 2023-04-17 7:35 ` Jonathan Wakely @ 2023-04-18 2:53 ` Puneet Kumar Yatnal (QUIC) 2023-05-05 11:13 ` Florian Weimer 0 siblings, 1 reply; 10+ messages in thread From: Puneet Kumar Yatnal (QUIC) @ 2023-04-18 2:53 UTC (permalink / raw) To: Jonathan Wakely, Puneet Kumar Yatnal (QUIC) Cc: Andrew Pinski, gcc-help, gcc-bugs [-- Attachment #1: Type: text/plain, Size: 5145 bytes --] What is next step here? How do I post this in Bugzilla and get support. Regards Puneet From: Jonathan Wakely <jwakely.gcc@gmail.com> Sent: Monday, April 17, 2023 1:06 PM To: Puneet Kumar Yatnal (QUIC) <quic_puneety@quicinc.com> Cc: Andrew Pinski <pinskia@gmail.com>; gcc-help <gcc-help@gcc.gnu.org>; 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), <quic_puneety@quicinc.com<mailto:quic_puneety@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 <jwakely.gcc@gmail.com<mailto:jwakely.gcc@gmail.com>> Sent: Monday, April 17, 2023 12:53 PM To: Andrew Pinski <pinskia@gmail.com<mailto:pinskia@gmail.com>> Cc: Puneet Kumar Yatnal (QUIC) <quic_puneety@quicinc.com<mailto:quic_puneety@quicinc.com>>; gcc-help <gcc-help@gcc.gnu.org<mailto:gcc-help@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, <gcc-help@gcc.gnu.org<mailto:gcc-help@gcc.gnu.org>> wrote: On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via Gcc-bugs <gcc-bugs@gcc.gnu.org<mailto:gcc-bugs@gcc.gnu.org>> wrote: > > > ++ > From: Puneet Kumar Yatnal (QUIC) > Sent: Monday, April 17, 2023 9:26 AM > To: gcc-help@gcc.gnu.org<mailto:gcc-help@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, &ts64); > } > #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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values 2023-04-18 2:53 ` Puneet Kumar Yatnal (QUIC) @ 2023-05-05 11:13 ` Florian Weimer 2023-05-05 11:16 ` Jonathan Wakely 2023-05-05 11:23 ` Jakub Jelinek 0 siblings, 2 replies; 10+ messages in thread From: Florian Weimer @ 2023-05-05 11:13 UTC (permalink / raw) To: Puneet Kumar Yatnal (QUIC) via Gcc-bugs Cc: Jonathan Wakely, Puneet Kumar Yatnal (QUIC), Andrew Pinski, gcc-help * 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 <jwakely@redhat.com> Date: Tue Nov 9 23:45:36 2021 +0000 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 b11cbbbb74b0e357652a1f1f0d93 ("libstdc++: Avoid calling undefined __gthread_self weak symbol [PR 95989]"). Thanks, Florian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values 2023-05-05 11:13 ` Florian Weimer @ 2023-05-05 11:16 ` Jonathan Wakely 2023-05-05 11:23 ` Jakub Jelinek 1 sibling, 0 replies; 10+ messages in thread From: Jonathan Wakely @ 2023-05-05 11:16 UTC (permalink / raw) To: Florian Weimer Cc: Puneet Kumar Yatnal (QUIC) via Gcc-bugs, Puneet Kumar Yatnal (QUIC), Andrew Pinski, gcc-help On Fri, 5 May 2023 at 12:13, Florian Weimer <fweimer@redhat.com> 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 <jwakely@redhat.com> > Date: Tue Nov 9 23:45:36 2021 +0000 > > 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 > b11cbbbb74b0e357652a1f1f0d93 ("libstdc++: Avoid calling undefined > __gthread_self weak symbol [PR 95989]"). > > Thanks, > Florian > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values 2023-05-05 11:13 ` Florian Weimer 2023-05-05 11:16 ` Jonathan Wakely @ 2023-05-05 11:23 ` Jakub Jelinek 1 sibling, 0 replies; 10+ messages in thread From: Jakub Jelinek @ 2023-05-05 11:23 UTC (permalink / raw) To: Florian Weimer Cc: Puneet Kumar Yatnal (QUIC) via Gcc-bugs, Jonathan Wakely, Puneet Kumar Yatnal (QUIC), Andrew Pinski, gcc-help 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 <jwakely@redhat.com> > Date: Tue Nov 9 23:45:36 2021 +0000 > > 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 > b11cbbbb74b0e357652a1f1f0d93 ("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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-05-05 11:23 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <DM8PR02MB7863C7021B8B36DAF9084509949C9@DM8PR02MB7863.namprd02.prod.outlook.com> 2023-04-17 5:40 ` Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values Puneet Kumar Yatnal (QUIC) 2023-04-17 5:53 ` Andrew Pinski 2023-04-17 6:09 ` Puneet Kumar Yatnal 2023-04-17 7:22 ` Jonathan Wakely 2023-04-17 7:27 ` Puneet Kumar Yatnal (QUIC) 2023-04-17 7:35 ` Jonathan Wakely 2023-04-18 2:53 ` Puneet Kumar Yatnal (QUIC) 2023-05-05 11:13 ` Florian Weimer 2023-05-05 11:16 ` Jonathan Wakely 2023-05-05 11:23 ` Jakub Jelinek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).