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 9B5E41F45E for ; Thu, 20 Feb 2020 16:08:30 +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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=sklB bluzb3FhvqNfSPcnKB/BCDm/dgYjqyLUnjOMIvptFhrSVYnefrJ9X80L/a39I/Au 4BEHCZNk7BSQoLlHpfPoAvZgC+WAcoq41MYcSXgScD5k7ngJVKzmD9L2IjlZj7ri dwN4xzY/LhcYuXuHhXNiLzNb9nJH1l7DCVannRc= 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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=QkUpzcS/Bs +nifIMrcGUabARuq8=; b=e/WxN5q6s/xp6EPh/AtueinyWowoGBuzaYN9iSH073 xREovNQMrydwINn8uOl3J3ZkvYJckN5WpZkfutj34hAPqBJ7w6zG/rJJiET4sSGf hUOoD0eLqjKm1iwV2qJD2bTUvcPgUzKK8bBphHGJANIg82WEc/bATdO0AVXXj8Wv 4= Received: (qmail 116731 invoked by alias); 20 Feb 2020 16:08:27 -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 116720 invoked by uid 89); 20 Feb 2020 16:08:27 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mout.kundenserver.de MIME-Version: 1.0 References: <4e95f95966d8d7c6a8339160dc62d81c1f6a1bfb.1578824547.git.alistair.francis@wdc.com> <00574bfb-981a-3a1c-cbdf-b2fee4eddc32@gmail.com> <8a9784b3-fc52-adc3-4595-33142b059388@synopsys.com> <20200220001136.2f14236e@jawa> <20200220103716.2f526933@jawa> <20200220141451.3fa2fc3f@jawa> <20200220164245.035e09b1@jawa> In-Reply-To: <20200220164245.035e09b1@jawa> From: Arnd Bergmann Date: Thu, 20 Feb 2020 17:08:06 +0100 Message-ID: Subject: Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64) To: Lukasz Majewski Cc: Vineet Gupta , Alistair Francis , Joseph Myers , Florian Weimer , GNU C Library , Palmer Dabbelt , Zong Li , Alistair Francis , Adhemerval Zanella , "Maciej W. Rozycki" , arcml , debian-arm@lists.debian.org, Helmut Grohne , Viresh Kumar Content-Type: text/plain; charset="UTF-8" On Thu, Feb 20, 2020 at 4:42 PM Lukasz Majewski wrote: > > On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski wrote: > > I do see two approaches here: > > 1. In glibc: > > When -D_TIME_BITS=64 is set - redirections are enabled for syscall > wrappers; for example __clock_settime64 is used instead of > __clock_settime (e.g. sysdeps/unix/sysv/linux/clock_settime). > > The latter is guarded by #ifdef __TIMESIZE != 64 so we could change > mechanically that __clock_settime returns -1 and sets errno to -ENOTSUPP What I meant is to remove the __clock_settime function from the library entirely to cause a link failure. I suppose replacing most "__TIMESIZE != 64" with '0' would do that. Ideally I'd just set __TIMESIZE to 64, but doing that would make the ABI incompatible with mainline glibc. > 2. In kernel - return -ENOTSUPP when clock_settime syscall instead of > clock_settime64 is invoked. We already have that with CONFIG_COMPAT_32BIT_TIME, but at the moment I think that still breaks glibc's usage of __NR_futex, and a compile-time error is always better than a runtime error, as it's easier to catch them reliably Arnd