From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 886001F463 for ; Tue, 7 Jan 2020 12:36:58 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:cc:references:from:subject:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=JPxSCkOKgMhc8Bao 2kB/5ugf52vsVCMtFCdRt19ILcWsliBHWyleMpbnf6pEMm885ZJk7s+kgXMhLOVq J6wRd9RxzOhmQ/AjDPxOf8OY8TrpjeXJ6Tq0rdGa8YJH4aThdNON7IkayGgd/12H 6lX8fN062CWBmWIItKE/5XBF8WA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:cc:references:from:subject:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=UBhjMuuFidrOBdsPqU762Y qnnWQ=; b=CcZS6wPdaXafD08E9LxdhnF0C6/rFfkYBTp+IF4y3Z9UxdPkrmOrgW 6HMuaIwaiB9CtMrigSUIArtNhcXx71XFQiWYlfFYWgv089JQep1h3objr2EKdaq5 tpp1bwmB1pgmb/m2Un0zez6TuYaS9A5wKRS6LlhUyRbeDHiToQGWc= Received: (qmail 10415 invoked by alias); 7 Jan 2020 12:36:55 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 10404 invoked by uid 89); 7 Jan 2020 12:36:55 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f196.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:cc:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=B0CCf9qJ26nQy87X6y3vtqAJnJgOCRg6s8vFwQ5EhHg=; b=Z2/FqsX4oV5YP8bQ8UyNwoiCNw8Ha1cX2bhSDrsHBkAaBO6tsZU9mjk7quAi3An8YK L+xCyjwfMS9crIvk9A1AydFF1/aXISo63OLvOgE7+aAK4CjU0xTA7NJWO+dV15wGWLqC nDRQaxmb0JDHMbh7hdj7k6l8dlrt7A7788ML+q5xI3wftYNqzTD4MuRQd46M0azWHYEw Rq2vGjPU7ixPDXq7FzF7xbafAtOfba1uHJv/hvSXG/elXJ0BNQ3TpSj/iPoVBz5P5/c+ Ycd10WgOZyP8hvr5kNGnJBO6BVd2Y01+ag+PbaAJWpNvuXE388GcblPlKwKXrXwuX+VO 1aaQ== To: Lukasz Majewski Cc: Joseph Myers , Paul Eggert , Andreas Schwab , Alistair Francis , Alistair Francis , GNU C Library , Siddhesh Poyarekar , Florian Weimer , Florian Weimer , Zack Weinberg , Carlos O'Donell References: <20200106121742.1628-1-lukma@denx.de> <20200107102752.396f7f6f@jawa> From: Adhemerval Zanella Subject: Re: [PATCH v4 1/2] y2038: linux: Provide __timerfd_gettime64 implementation Message-ID: Date: Tue, 7 Jan 2020 09:36:45 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20200107102752.396f7f6f@jawa> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 07/01/2020 06:27, Lukasz Majewski wrote: >> As a side note, now that arch-syscall patch is upstream should we >> assume that for !__ASSUME_TIME64_SYSCALLS the __NR_timerfd_gettime64 >> should be defined (meaning that Linux supports time64 for all 32-bit >> architectures)? > > Only Linux version >= 5.1 supports 64 bit time on archs with __WORDSIZE > = 32. I do guess (but I may be wrong here) that the arch-syscall is > supposed to reflect the exact syscalls provided by kernel headers used > for building (to help with validation of Y2038 patches). The arch-syscall is now autogenerated from the latest kernel release defined in build-many-glibcs.py. So the question is whether Linux support and enforces time64 support on all and future 32-bit architectures or if there is still some missing ones (as it has happen on some syscall additions, where some architecture lag behind some releases). > >> >>> + struct itimerspec its32; >>> + int retval = INLINE_SYSCALL_CALL (timerfd_gettime, fd, &its32); >>> + if (retval == 0) >>> + { >>> + value->it_interval = valid_timespec_to_timespec64 >>> (its32.it_interval); >>> + value->it_value = valid_timespec_to_timespec64 >>> (its32.it_value); >>> + } >>> + >>> + return retval; >>> +#endif >>> +} >> >> >> Ok. >> >>> + >>> +#if __TIMESIZE != 64 >>> +libc_hidden_def (__timerfd_gettime64) >> >> Ok. >> >> As a side note, we should fix it on clock_{get,set}time to add the >> missing libc_hidden_def. > > The clock_gettime already has libc_hidden_def. The difference is that we > use some compatibility code (after moving clock_gettime from librt to > libc) instead of strong_alias (as it mimics the behavior from auto > generated syscall wrapper). I meant for the new time64 symbols. Currently it is not an issue because the internal time64 symbol is not exported and static linker uses the internal __GI_ name for the symbol. For instance, objdump -t on clock_gettime.os on a 32-bit architecture (powerpc in this case) shows: 00000144 g F .text 00000088 __clock_gettime 00000144 g F .text 00000088 __clock_gettime_2 00000000 g F .text 00000144 .hidden __GI___clock_gettime64 00000144 g F .text 00000088 .hidden __GI___clock_gettime 00000144 g F .text 00000088 clock_gettime@@GLIBC_2.17 00000144 g F .text 00000088 clock_gettime@GLIBC_2.2 Where with a libc_hidden_def (__clock_gettime64) it shows: 00000144 g F .text 00000088 __clock_gettime 00000144 g F .text 00000088 __clock_gettime_2 00000000 g F .text 00000144 .hidden __GI___clock_gettime64 *00000000 g F .text 00000144 __clock_gettime64 00000144 g F .text 00000088 .hidden __GI___clock_gettime 00000144 g F .text 00000088 clock_gettime@@GLIBC_2.17 00000144 g F .text 00000088 clock_gettime@GLIBC_2.2 The requirement of libc_hidden_def will de defined in the end if glibc exports or not __clock_gettime64 on some header redirection or if clock_gettime64 would be suffice (with a {weak,strong}_alias). However I do think we should fix it to avoid such confusion why there is a hidden_proto and not a hidden_def.