From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id C30763858CDB; Mon, 17 Apr 2023 05:53:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C30763858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x634.google.com with SMTP id o2so24460823plg.4; Sun, 16 Apr 2023 22:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681710835; x=1684302835; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WgQ+I925rThMyKqjKi0tdh4+pM7CpL+ZkMdTOWq5xJA=; b=lIHspWgZpyeSjWru+RpqOg+HTcmBmINqF/pzq35w7oXBI6pmko/mLCX2DGfu+/anV+ wNp5hQ8VfSz74UNaSgId1ndtUrUnsiZkR2AwyCALV1B8ojFKBNSvT3uj+ZKe7O8igWq0 GIexOTepjA4ErkGgv7b//eOL6TXMVhxsI+jqK5fetdxQoMiZZ7qD0U54vm8VISzPwD8t pm3rAk1XJD7BdCKB8EZeUIro+Rssr54oixiIbPn+7c4UK3L1EuqihBv3vMA+8q7ZtusQ ThLNfzsOCHcsI/q+e/Ef3L9nlEIsvFV8XozHBwP30xG8cBRJvom/2XttRUVOBlX5OMYO EmNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681710835; x=1684302835; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WgQ+I925rThMyKqjKi0tdh4+pM7CpL+ZkMdTOWq5xJA=; b=LZsF/6CIdZxac+x857It4Mjn5pX2+iYD886LtnYHn+sh409ESmpNOP/ccgSPZxMivh hVjNqTOmr2WdvBY8yEFEH5zTPuiuf8faM80qjjyJrVwi3inCMVMxa1UOAMnJeLIGe0v2 RjPVyDcACuKrzOLOiDduIKIJtD+fpd7o0KrRNujJNLTCi00G4CF//8TwA0i4CnJyDrWc hVADRMhpBDs6m1gyhoQ++meNoOUxbB74rXkbuKue8crcfwEoC2Y+HsNz62Mml1Sn5F7u 3ZNUdDdMgokCWI2Esvc6Yxda9MQAcRVg2PuK6lByPTOiXYMo5X3XBPSOs9t7E+nRdZpA CRLw== X-Gm-Message-State: AAQBX9cDVPlMfDvz1f9f2otoaWtyVl/KDJezv8QL8bySl10R2wnvMRbQ d9V+WxFirt8DxTEJwwReAojx6QSjSCno2klIeLA= X-Google-Smtp-Source: AKy350YUzUhPeczOl1ZGtfs8AEzrsayhEv0FTZnLwJ1uZBp1/9H31gicaWZ8uZsIPqv7JZi+rBDRzuD8Z522iyH5uvg= X-Received: by 2002:a17:90a:1303:b0:247:2dc4:91d5 with SMTP id h3-20020a17090a130300b002472dc491d5mr12673957pja.0.1681710835591; Sun, 16 Apr 2023 22:53:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Pinski Date: Sun, 16 Apr 2023 22:53:42 -0700 Message-ID: Subject: Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values To: "Puneet Kumar Yatnal (QUIC)" Cc: "gcc-help@gcc.gnu.org" , "gcc-bugs@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sun, Apr 16, 2023 at 10:41=E2=80=AFPM Puneet Kumar Yatnal (QUIC) via Gcc-bugs 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 impa= ct 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 b= it ), pthread_cond_timedwait function from gthr_posix.h is calling differen= t 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, pth= read_mutex_t *__restrict __mutex, const struct timespec *__restrict __absti= me) __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 v= alue as __pthread_cond_timedwait is converting value from 32 bit to 64 bit. > > normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 prop= erly and its working fine. > > From: pthread_cond_wait.c > > #if __TIMESIZE =3D=3D 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 =3D valid_timespec_to_timespec64 (*abstime); > > return __pthread_cond_timedwait64 (cond, mutex, &ts64); > } > #endif /* __TIMESIZE =3D=3D 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 resol= ved but that is not correct way as it disable weakref for all symbol, pleas= e 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 >