From patchwork Wed Jun 14 20:15:26 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Palmer Dabbelt X-Patchwork-Id: 775961 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 ozlabs.org (Postfix) with ESMTPS id 3wnyZJ2Mqhz9s4s for ; Thu, 15 Jun 2017 06:16:08 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="yIfdsJOz"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:cc:cc:cc:subject:in-reply-to :message-id:mime-version; q=dns; s=default; b=Vd6BV8q/Bt63Wwbh5G zmFOl3AJmgevmnBWyM65wQxVstY4uHSP9H7U869/LzRXuw/lILW8deYc4zdb9NeX Hjzj7dqmRmaYSncUHS3aff3hkP1xv4JEVgArPjzRb47YGuTBM3v7DLGYLM3WwU9L QHmZssrRWQ4RLtIFD8mZnmO44= 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:date:from:to:cc:cc:cc:cc:subject:in-reply-to :message-id:mime-version; s=default; bh=HbX7LVllB4hPVYZKPAkvUvsP YKI=; b=yIfdsJOzsDbWe46o5QM3aQlQPN0N9O+K1gEBROjXWRlkgIq42eiWliEy Pqm4WUhOsQHVbgpEV8BuNciygxZeElMg+jC+NnqZiFQSBTTK8d0HV1J/+aAcso+z Q743rsXQjJ7OVS+kwNGcrGfOibSxvLc4Isl2kSSAokPAkimSsks= Received: (qmail 7287 invoked by alias); 14 Jun 2017 20:15:46 -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 Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 6875 invoked by uid 89); 14 Jun 2017 20:15:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1624, recommend X-HELO: mail-pf0-f176.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:cc:cc:cc:subject:in-reply-to :message-id:mime-version; bh=3E3UaxPdVm7Q4eQ6gVvb54oPeprEqVW3iGwn1hqmDrU=; b=iLRpKLyBzmVz+SC82zV6BCdfHqQbZdv2bYA1Y4PkV4mT0LNCCIlBZFMuF8XI1b6U8+ yCbwp1jdsM1DEgmSpAzG7dD+ZjVOhZavV2elXJDUBAdai5PmstYupt0Fr39b091oPpLb LW11rVvj9iVxUgNWCE6lzl7dID7no1hFM4fUo0NoR9QIBJnwWvz8iDIpdpmXDXtjaysx s24zE0Xt1PbgJS1S5bvmuAier0U+eivLiAPmcPGVHtfc9+Qvx+yvo4hNcfOyaGnOyF5f bssf4/esh4Rn1APxg1fbeZcibzndKP+xZcnHUYvEHHn8mNtDP/ma2N+GLLcMSzyGGQ3d oLRg== X-Gm-Message-State: AKS2vOzv+b+OcXr9ZSnXAZDTXlcZ2m8Q4fOPsWxu3hVa5CyIfYRBVvR5 EOQHUnhDiEyEz3Qj3NaWBA== X-Received: by 10.101.88.130 with SMTP id d2mr1753261pgu.58.1497471326909; Wed, 14 Jun 2017 13:15:26 -0700 (PDT) Date: Wed, 14 Jun 2017 13:15:26 -0700 (PDT) X-Google-Original-Date: Wed, 14 Jun 2017 13:14:37 PDT (-0700) From: Palmer Dabbelt To: fweimer@redhat.com CC: libc-alpha@sourceware.org CC: Andrew Waterman CC: patches@groups.riscv.org CC: Darius Rad Subject: Re: RISC-V glibc Port v1 In-Reply-To: <87h8zi1gnz.fsf@oldenburg.str.redhat.com> Message-ID: Mime-Version: 1.0 (MHng) On Wed, 14 Jun 2017 13:02:40 PDT (-0700), fweimer@redhat.com wrote: > Palmer Dabbelt writes: > >> This port targets Version 2.2 of the RISC-V User ISA, and supports >> both the RV32I and RV64I base ISAs as well as the M, A, F, D, and C >> extensions as well as our Linux port which is based on the 1.10 >> supervisor specification. > > I would recommend to delay the addition of the 32-bit port, so that you > can start with a 64-bit time_t. Do you have an idea of when there will be a 64-bit time_t clean release? I'd be OK holding off on the 32-bit port for a bit, as we don't expect RV32I-based Linux-compatible systems to be popular. One sticking point is that the RV32I and RV64I base ISAs are very similar, and as such share a lot of code. I'd prefer to avoid removing the rv32 code just to add it back in later, as that will be a big headache. Would it be sufficient to just disallow RV32I in our preconfigure with a patch like this, and then turn RV32I back on when we can support a 64-bit time_t clean ABI? diff --git a/sysdeps/riscv/preconfigure b/sysdeps/riscv/preconfigure index 43e2a4fac0..a15e563a31 100644 --- a/sysdeps/riscv/preconfigure +++ b/sysdeps/riscv/preconfigure @@ -3,7 +3,11 @@ flen=`$CC $CFLAGS $CPPFLAGS -E -dM -xc /dev/null | sed -n 's/^#define __riscv_fl float_abi=`$CC $CFLAGS $CPPFLAGS -E -dM -xc /dev/null | sed -n 's/^#define __riscv_float_abi_\([^ ]*\) .*/\1/p'` case "$xlen" in -32 | 64) +32) + echo "rv32i is not supported, we're waiting for a 64-bit time_t clean ABI" >&2 + exit 1 + ;; +64) ;; *) echo "Unable to determine XLEN" >&2