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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-5.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 7A0791F8C6 for ; Thu, 19 Aug 2021 12:47:05 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B0D123888031 for ; Thu, 19 Aug 2021 12:47:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B0D123888031 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629377224; bh=rDMn/TS80OOYEza44M5QxjGEooPEgV/AgKqBFia4eiY=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=Y97tVPozpnzCdqurNE2KybCzccfrBFE6rsfxyLr3/TQVS1xdNGDSTbLa79/2Hh4WF AWAbHRka3hjG1uAi6iK+y3eFyVYdDBluQK1UTlrDsH+OVbUDHqqHTUPhBqZFt1KtPq KIBIS06jvOeDO8kXNlgNTQ1V0tq1InCC/uxcmcKU= Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 29788385BF9C for ; Thu, 19 Aug 2021 12:46:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 29788385BF9C Received: by mail-pj1-x1030.google.com with SMTP id j1so4846862pjv.3 for ; Thu, 19 Aug 2021 05:46:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rDMn/TS80OOYEza44M5QxjGEooPEgV/AgKqBFia4eiY=; b=JxElzOwgOTklKFWX+1mS1rOarBjITjv3TitobKejK/T42Wv/WCJKE2MsMWvxYDfmO3 vx33q3zMv6MeaehE6faxN9CghiRAePqYNRe3OfBZXohP3AFkpfLQBHiScb9aKUuTvoXw qXDqV5PSBL67bvISQmzQyhDj8PZz1K4UhO4adpK8FyroMjtG8pQ4EXwUOh4QVUCdsAlF n2zrekddEQ5uuwWr1uzbRG1bOyXfsqa0TPnlumeDt/uT6ns0pzGpqxae29ihLEB1psmi HZzQyhOkftYBBKEu4HXwdfJtz7LzI1nRrBwpuyuBW712P9dtEpc80BixWYT2ddlJ+DoM +leA== X-Gm-Message-State: AOAM531QPHvnHb1fa8EsvVdLYECqbI7TRcxZlDnL3u0vk33vQVKr3qMY uuzikeI4TW4D3tyDa2HUwCF++Odam9yAPg== X-Google-Smtp-Source: ABdhPJwLETTcWTHAEBz+mzyIfurucfoL4eYxaNi6G1ae68GNaXWf82D8XHNpP/08WIa1vUBJa5nb9w== X-Received: by 2002:a17:90b:3794:: with SMTP id mz20mr14721477pjb.63.1629377194151; Thu, 19 Aug 2021 05:46:34 -0700 (PDT) Received: from ?IPv6:2804:431:c7ca:cd83:aa1a:7bd:9935:9bba? ([2804:431:c7ca:cd83:aa1a:7bd:9935:9bba]) by smtp.gmail.com with ESMTPSA id y6sm2973720pjr.48.2021.08.19.05.46.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Aug 2021 05:46:33 -0700 (PDT) Subject: Re: [PATCH v2] time: Fix overflow itimer tests on 32-bit systems To: libc-alpha@sourceware.org References: <20210806094217.3227877-1-shorne@gmail.com> <0f577bc8-bef8-6c06-aaa9-57bf16d8443b@linaro.org> Message-ID: <80541465-44f0-0c1b-b43e-f89df052f143@linaro.org> Date: Thu, 19 Aug 2021 09:46:31 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Adhemerval Zanella via Libc-alpha Reply-To: Adhemerval Zanella Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 17/08/2021 20:33, Stafford Horne via Libc-alpha wrote: > On Tue, Aug 17, 2021, 7:33 AM Joseph Myers wrote: > >> On Tue, 17 Aug 2021, Stafford Horne via Libc-alpha wrote: >> >>> Should we provide __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 for not linux >> builds, >>> or remove __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 from the itimer test >> again? >>> The reason for using __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 is to pick >> up the >>> timeval size which is different on each architecture. >> >> I'd suggest having a macro that doesn't refer to either "kernel" or "old >> timeval" (and that is defined for both Linux and Hurd). As far as I >> understand, the logical concept that's relevant for this test isn't either >> one of those, it's more like "setitimer supports times that cannot be >> represented in 32 bits". >> > > Hello, > > That makes sense, currently with the hurd build being broken how urgent is > this? I worked on reproducing the build issue with build-many but didn't > get it working yet, probably about 80% there before I ran out of time. > > I'll try to get it fixed in a few days as my top priority, but I only have > an hour or two a day to look at it. If we need to revert or add a temporary > patch please feel free. The most straightforward would be to add a libsupport routine to abstract what Joseph has suggested: support/xtime.h: bool support_setitimer_support_64_bit (void); And return 0 for hurd and __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 for Linux.