From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 36EDC3858CDB; Mon, 17 Apr 2023 07:35:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 36EDC3858CDB 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-ej1-x631.google.com with SMTP id xd13so27716881ejb.4; Mon, 17 Apr 2023 00:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681716950; x=1684308950; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i8SM9B6RVXvS4DdF0pFW7N/vmVDxPLYRORUW8iYlrgQ=; b=OUrGcwvoWymLQK/2QRIarf2Tbev5+NXBu+W3fmM0u+Sdk5zT+axDXfiZR3razn70aG yJP1m5vqo1mP7gj4a8Tk4TsaZnRmgFvB4zvgwNob+CWfDPkfkO06qLitDB+rXr2f59ZG +XyU9l91ep5JioNJnYHnVpmjA/Jy9s13tYCzwlv8FK+axBcgMM+KQuMIWoh/fH9AgW5q YqwZA64wMeExIJdmHN6TC3euw0NLf+TQg1Qo+BIaT4Acxr1LIbyMwqQtyWfFD2oO9XZl VZxf69wa8vUjNnWgyi3HIutpxh71XrsTZgPB0BQ2NNcJRreSApMxzQSOh/sMtDLufh63 sS7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681716950; x=1684308950; h=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=i8SM9B6RVXvS4DdF0pFW7N/vmVDxPLYRORUW8iYlrgQ=; b=Q/6/rFmqTU/vAoSjdwrL1gbb2x4y3FYws8eUELRaSL6HD52q8EwkTUO9R4VA12O6/r 69x5Lq1FJTuvNYMNB/vAPPCuNQLvaVEQNO6GpzmV5133u+moNX7OYoAJQ0QYWxFs0Uzf fbxQyxgjRsqEHo+3bxU3cC8ZfKnM5qVCESpt7q9T+0dLjYfYS6W1s0fxvsqmK8AIj4e5 Hdle65d5m71KF/8Y2SOkGkCUt3RrYHAONd/uQvsEr60hHQwnb87fINrZb0F1c3bSQiY5 sO4SvbeP0hdbg3ZkIHjtsjwMfuDGqZ61/uQuN3lYWVETBxHXKaTYkstrb5apx+ScAKNT IlvQ== X-Gm-Message-State: AAQBX9fXtT9en1H0m6RYWewEzwOK6DMe4A+5zB3vvqruT9HAbYCTLAbs NJplSiFWzh2ATmEIOrZbHm22pk3cuidCNBBjzXE= X-Google-Smtp-Source: AKy350bIdlDQvJstM0V2qMMX5kEkDmbH8P6y+rHAOMDqqK8IyrPZgo1kO2NUj548p3FxwaQ7ORl/98rE52PQ86e4yTs= X-Received: by 2002:a17:906:7186:b0:90b:53f6:fd8a with SMTP id h6-20020a170906718600b0090b53f6fd8amr7341858ejk.10.1681716949818; Mon, 17 Apr 2023 00:35:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Mon, 17 Apr 2023 09:35:38 +0200 Message-ID: Subject: Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values To: "Puneet Kumar Yatnal (QUIC)" Cc: Andrew Pinski , gcc-help , gcc-bugs@gcc.gnu.org Content-Type: multipart/alternative; boundary="00000000000068228505f9833dd9" X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,KAM_LINEPADDING,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000068228505f9833dd9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 > *Sent:* Monday, April 17, 2023 12:53 PM > *To:* Andrew Pinski > *Cc:* Puneet Kumar Yatnal (QUIC) ; 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=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 > 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 =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 > 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 > > > > --00000000000068228505f9833dd9--