From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by sourceware.org (Postfix) with ESMTPS id F1A41386480B for ; Wed, 11 Aug 2021 23:21:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F1A41386480B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pj1-x1033.google.com with SMTP id w14so6139441pjh.5 for ; Wed, 11 Aug 2021 16:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20150623.gappssmtp.com; s=20150623; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=qI6i4PfLkhlJ0cA7mUjB5vhuXcJLmZkivjfBwLKG68Y=; b=kZQUzaBEJOBPUyKgR2s5ze/sRNwnmpj8VthkfQ6Ub2C3xD8BgZs0WFEZAM3IhBBqLV +u26ZTb+W137ogN1K0nZ7rtB7t9JL0L5WANRgkLweBjd7CwxS7lSaiVe4TmhD1pVEE0o hfmtiSuLtKdNS3OeZsZpNrAzmmgiasWmw+mYn+YQqqcQZWWOUpIiYYijOWeDb3C+wU5E d6KeKmoP7mdDgNjf/Ln4pdhpxyaseoW2Zown4KFNuEIApmpC9TN7I2QO+04agw/m3iij B6mi/uSrJ0kk46vw6kWQVprq0vNKl+5HSr2M9hV0f6EpEgUjoSPqnf0plUBrZDPYLvsP YgPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=qI6i4PfLkhlJ0cA7mUjB5vhuXcJLmZkivjfBwLKG68Y=; b=Vp0dL2+31OAv2i4HS24DFvuI6ODMOhHgKIby4lxyhVsmqahK6YDyE0vUX+Qx1axzDI SHas2DZoCbieXV3TsXKePuTDrSSd3FmPXZUT7wCW+hLNnEuBzxXONqmgdDX4sh9TeRoy RAcupw3eGd/fqFhG+5I0g3UGdWfG6RVBVa1PHMeAmo5sVLuQbbh9lx+nYBEnSyOcB0Mt i7dpllUmx7aCmWO1j8KJvXlzmR1fyieB7PCannB/KPO4zlIUdCRkyEcOwHHH55V/LR4M VF3irpn7fZbFMDvV/fP0lw1DMM0gAeeCLNQzH9v80C04LuIF5FaA5qTqNWN1n0fvF6G/ 0ofg== X-Gm-Message-State: AOAM532uPfudxqQ3k/6jlNjxd4zPGbMk2R9hog7KbhfC+RNi72j2beOY fRM58dDJF8p0ikx/hiQ8mYFmeg== X-Google-Smtp-Source: ABdhPJwaTumKosBzRMNABXxNQ6FMEtjl819bpsPjh28x1DYxKGn/1+USkwieqSet/baHYrB5nnLCdQ== X-Received: by 2002:a65:468c:: with SMTP id h12mr1067677pgr.423.1628724074912; Wed, 11 Aug 2021 16:21:14 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id e31sm556457pjk.19.2021.08.11.16.21.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Aug 2021 16:21:14 -0700 (PDT) Date: Wed, 11 Aug 2021 16:21:14 -0700 (PDT) X-Google-Original-Date: Wed, 11 Aug 2021 16:21:11 PDT (-0700) Subject: Re: [PATCH] riscv: Resolve symbols directly for symbols with STO_RISCV_VARIANT_CC. In-Reply-To: CC: kai.wang@sifive.com, libc-alpha@sourceware.org, Andrew Waterman , kito.cheng@sifive.com, jrtc27@jrtc27.com From: Palmer Dabbelt To: Jim Wilson Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, LIKELY_SPAM_BODY, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Wed, 11 Aug 2021 23:21:18 -0000 On Wed, 11 Aug 2021 16:00:31 PDT (-0700), Jim Wilson wrote: > On Wed, Aug 11, 2021 at 3:13 PM Palmer Dabbelt wrote: > >> I'm trying to stay away from the foundation stuff these days, but from >> reading that spec it doesn't look like the variant CC has anything to do >> specifically with the V extension but instead is about allowing for >> arbitrary calling conventions for X and F registers as well. Handling >> non-standard X-register calling conventions is really a whole different >> beast than handling non-standard F or V register calling conventions. >> It's not crazy to allow for these, but lumping them all into a single >> bit just makes this unnecessarily difficult. >> > > This is the exact same solution that the aarch64 port uses. We aren't > inventing anything new here. > > The intent is not to support arbitrary calling conventions. The intent is > that we will have two official calling conventions once we add vector > support, one that uses vector registers and one > that doesn't. Most code will use the non-vector register ABI, and we > expect glibc will be compiled this way for maximum portability. But we > will need to support the second ABI that does have vector registers, and > hence we only need a single bit for that at this time. > > If you aren't willing to participate in the official ABI committee, then > you should at least be willing to accept their decisions. All I'm trying to do here is point out that the ABI you've defined has some much broader costs to implement than the features you're advertising you want to use it for. If this is the ABI you want that's fine, I don't really care, just go make it part of the official psABI spec and we'll get on with our lives. > and would still allow us to have lazy binding for the variants. At a >> bare minimum we can support arbitrary V register calling conventions for >> free until we start using the V registers in glibc, which is likely >> quite a way off. >> > > We already have patches to use V registers in glibc, and we are already > using them. We already upstreamed the ifunc support for binutils and glibc > required to use vector instructions. We use them for mem* and str* > routines. Adopting the position that the resolver isn't allowed to call > any mem* or str* functions is unreasonable. Hence the need for this patch. > > Jim