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=-3.6 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 255B01F8C6 for ; Wed, 11 Aug 2021 23:33:01 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 199683992032 for ; Wed, 11 Aug 2021 23:33:00 +0000 (GMT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id 7391B3990C33 for ; Wed, 11 Aug 2021 23:32:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7391B3990C33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jrtc27.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jrtc27.com Received: by mail-wm1-x32d.google.com with SMTP id i10-20020a05600c354ab029025a0f317abfso5629666wmq.3 for ; Wed, 11 Aug 2021 16:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jrtc27.com; s=gmail.jrtc27.user; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qcOkbxCWyHISxGlzgl/RO+pgDbFrYoddvE7aRRnUXYg=; b=OPHiBtiIKVV0Ej4tED8Hgq5l1ZrVvDCKto6FA279/6CpmrLcO/JB/deVABUnJfdO35 GFNyUnSf5K3szkIqbKjyqVm1KTX7tveGw0K65C8iSqIfY9dOqfwiRyAFIrzV2VVnd2Vw LpW2C/iklKI9RtMmfAtaUXWIPVFckzzjzI9eJrsaj6SuE0SwjP7Ea52u/aiY/admuOgi d8gTJHXqe9bnXRNP5ppRoCxC25/v3Z53ZJ12+mJDeeq7lHZRIvAVl3Y5BF1jFpr+OlOn k55376b9UCq1T67aptBOl4Qbihm8W+qdB0m7X/Bldfy4muhg6RMgleRJFT5YtxliAuno 09Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qcOkbxCWyHISxGlzgl/RO+pgDbFrYoddvE7aRRnUXYg=; b=saNPqtFMlraPDK1xPgJR81JaOK2YzjwfPEuLR8wQagQDStwDDY1p261sf/PgboPXBm 4HGcVPVQMj9EABNGaDUJ12aUQljMsI2AA2SJjhwi+ZBpqXc8FCTW5TI+qz1V8dBQRqTa tAemIZDzoRiIz4l1fNRnVQ7rRyDlo6/5zKrtgfgUG7vN4gBl5x9vUC2vFYWAvp1X3rMB D6zs16Xp8Gl8r4O6BS0Z1QyRjE0n7GR8m6WIAqPagVdFk8KNOzlzbUPSNe5PHpM8xkLC gEr0Z8gGJMZQf9kOP4u4p881Da+3DADB7cTlWlp4g7Y6+ZMv1ffpWEtTTPdDFZeoua2G wKzg== X-Gm-Message-State: AOAM533IQ2f6/iY+TUqDVCOiYxwVgR3Trx4ID9Vt4uR40pGHMI9OxsOP qCWZFh/Ek3z80oRtIQ3UZM6W2g== X-Google-Smtp-Source: ABdhPJzB74iUL1nz7EU9BqtdbynsupCUSQant61xGXBvbMXXTFfsYISJAh2hGWMJmtMyiWVB+sUkxQ== X-Received: by 2002:a05:600c:49a2:: with SMTP id h34mr917930wmp.10.1628724759563; Wed, 11 Aug 2021 16:32:39 -0700 (PDT) Received: from smtpclient.apple (trinity-students-nat.trin.cam.ac.uk. [131.111.193.104]) by smtp.gmail.com with ESMTPSA id 6sm618069wmk.20.2021.08.11.16.32.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Aug 2021 16:32:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: [PATCH] riscv: Resolve symbols directly for symbols with STO_RISCV_VARIANT_CC. From: Jessica Clarke In-Reply-To: Date: Thu, 12 Aug 2021 00:32:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2907E02A-7AC9-4D39-8252-9E43A2B34992@jrtc27.com> References: To: Palmer Dabbelt X-Mailer: Apple Mail (2.3654.100.0.2.22) 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: , Cc: kito.cheng@sifive.com, libc-alpha@sourceware.org, Andrew Waterman Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 12 Aug 2021, at 00:21, Palmer Dabbelt wrote: > 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: >>=20 >>> 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. >>>=20 >>=20 >> This is the exact same solution that the aarch64 port uses. We = aren't >> inventing anything new here. >>=20 >> 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. >>=20 >> If you aren't willing to participate in the official ABI committee, = then >> you should at least be willing to accept their decisions. >=20 > 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. As I explained in my reply, in practice the solution for the vector = calling convention specifically ends up being the solution for the more = general problem, and so there are no such broader costs beyond the = edge-case you identified that=E2=80=99s just an underspecification = issue. Regarding making it a part of the psABI spec, it has already been = approved by all relevant parties, it has just been waiting on a = proof-of-concept, or better, patch for either glibc or FreeBSD, which = this provides, since for important features like this our policy is to = not merge additions to the psABI spec until patches exist to prove its = viability. Jess >> 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. >>>=20 >>=20 >> 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. >>=20 >> Jim