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=-2.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_GMAIL_RCVD, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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=no 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 470B71F55A for ; Fri, 21 Feb 2020 19:57:15 +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=PUF0 B5A0WxJJ3LzvN1UGL8jfS40Wa6NtvCEnBq5qDZ3yDa6pl6KR/vTD3Dv02gVWIl3Y 2wBkySyaBVlhIk8YOUTj31sw6ffGbUJ2gUzScGkJ46CSuY+EHl/DHv02QmwPUaML U3wJDMaw1sfabB9Hqn6/XW6JKgsE5ghPHtkypws= 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=hOCKc71gGF KGIofsY+a+1DyczFE=; b=SCEvKLeU8o5/mWmavKfpTRrb4GhTocwMs2LcIQjA1K TNJkpMmtwcLWhoUOqBVV4yolcP6h/4gdflAxGAxx4RDsYWTY6QYnUYSTeVD78qK4 euSdzFeq70mgVM708Pvt85m+zLAZBUX1RhpSnAhXWsUKcoO1nHnw2Qh65+I4ISNe I= Received: (qmail 129206 invoked by alias); 21 Feb 2020 19:57:12 -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 129190 invoked by uid 89); 21 Feb 2020 19:57:12 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-lj1-f194.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oO/0oVAREgr5MfORTF+oGjH3ppE6bYdphuMutbzWe50=; b=S87U37rz4HAdl8X08Xan5Oeck91WSZLmvEQsW9EHVq6zXrZzArk62W6tVWAe/wgh2E O7/5XgcKLdZYc4sFW/TU/Wkh90ud4Qp7UKY/dOpC/wVPrXmnnkt/lZ/I2fMylk+HJ7Dd p/X3qIrBxAt5/IYqU7kIsS0G/U32KgOaYJDQG7Pel5YMHZYli0xywJ+OLmj2ROJIt5hs kj0pD/LIhEXBLk6ltBKFJqk3NhTi3fNq5DH8rfHWCT4j+A4F9Q9GTGRkeNPajkBpf4vl bMCIgQNKrg5eN8MqZqkXMVVeSM1tTJzbpUqdvYfSXpE+YL7o5V8x72tM5DAzlQ5XjB5k nQFw== 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> In-Reply-To: From: Alistair Francis Date: Fri, 21 Feb 2020 11:56:38 -0800 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: Arnd Bergmann Cc: Lukasz Majewski , Vineet Gupta , 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 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 20, 2020 at 4:37 AM Arnd Bergmann wrote: > > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski wrote: > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski > > > > > > Would it be possible to take a snapshot of your glibc tree > > > > The description of the status of Y2038 supporting glibc on ARM 32 can > > be found here [1]. > > > > The most recent patches for Y2038 supporting glibc can be always found > > in the 'y2038_edge' branch [2]. > > Ok. > > > > and start testing this out with debian-rebootstrap [1]? > > > > I've been using OE/Yocto for testing as it allows building glibc > > sources for x86_64, x86, x86-x32, arm32 (probably also for ppc32 and > > mips - but not tested). > >... > > However, I did not yet tried debian-rebootstrap. I will look if this > > can be reused as well. > > The reason I'm asking about debian-rebootstrap is less about testing > glibc itself than about testing the rest of user space to figure out better > what needs to be done when rebuilding with _TIME_BITS=64, and to > start fixing more upstream packages, with the hope of having enough > of it done in time for the Debian 11 release. We have started to do that for RISC-V 32-bit. I have fixed up some things in Busybox and OpenSSL to improve 64-bit time_t support on 32-bit archs. In meta-riscv (and OpenEmbedded layer) we are tracking issues: https://github.com/riscv/meta-riscv/issues/202 Right now it's all compile focused though, not so much run time testing. Alistair > > > > Are there any glibc issues that prevent it from working correctly, > > > > I think that the glibc wrappers for most important syscalls are now > > converted. > > > > What is missing: > > > > - NTPL (threads) > > - stat > > Do you mean that code using these will fail to work correctly with > -D_TIME_BITS=64 at the moment, or that the interfaces are there > but they are not y2038 safe? Without pthreads or stat, we probably > wouldn't get too far in rebootstrap, but if the interfaces are there > and mostly work, then we don't need to rely on them being > y2038-safe just yet. An obvious next step would be to run the > resulting code with the RTC set 20 years ahead, and that requires > it all to work. > > > - In-glibc test coverage when -D_TIME_BITS=64 is used. I do have > > some basic tests [4], but this may be not enough. > > This is probably something where debian-rebootstrap could help, > as building and testing more user space packages will excercise > additional code paths in glibc as well. There is also some work > in Linaro to ensure that LTP tests the low-level syscall interfaces > in both the time32 and time64 variants. > > Arnd