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 134BE1F8C6 for ; Thu, 12 Aug 2021 00:54:43 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 59F51384000E for ; Thu, 12 Aug 2021 00:54:41 +0000 (GMT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id 8F1C43857020 for ; Thu, 12 Aug 2021 00:54:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8F1C43857020 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-x333.google.com with SMTP id l34-20020a05600c1d22b02902573c214807so5746277wms.2 for ; Wed, 11 Aug 2021 17:54:20 -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=w8W0z7qgNjQVyZHxUWZvrhFVLiKA4rheZW9KyfWk/8M=; b=W2Gk0hDGMBjrrMHtwMRvQVFf8iimWHZHj+0iuIMa3g+0GaOtOdhx65tPuV/i86GHke 8qr6WNGuhREHybmAVTQWgu6fDn3iOskD8Aq3UehS97Siafdtx3JgBA08h9zOzdqRT11h bTMyTzQpWcFk8OwnquXAJd8sWkuQU1fZfYuqMG7nyU9eb/1PefPi3kXH6y6EuzhkVb2G +Jnu04lS4mktJO5hGnAe+Vh8nsTv5CapRHeqpfEkmkwX0rmeplE75eRE3EkgznP5wC5O QVlKbJbpI7k4B7S4x5+GcvjCSOQmGrmRGbwNkSp0kT9qajWtIXhehRPQgzJKGzZ6QvkC VTIQ== 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=w8W0z7qgNjQVyZHxUWZvrhFVLiKA4rheZW9KyfWk/8M=; b=gLrZPvvSnYwaOuGsTbLX2qhOktb15oW4zgEbqAPHMUHB1SmG1cyG3JemcnIBO5qY1X /YZeEcqK18kheavZxlloKOC43RYJf9njWjdT71sOaVWtDEw2wzeEqLQvqN1FzCsrE6gb TuBMMj+yTm+lqwjakYhKu+mK8YsQX+eZ/a8FRIDQcAMrnx0hmo/EftPvDwP9WE7NgNor 020WeqUTZZpunfVz+IlcuEg+UmFw6MbirJkboBOmOPswEZxBUQUzLOa+zBJ7PYEK88Bx tT/98KpJtv+r1v5tDc1Cez1caC8U1gbwU1fOq2CNADEZxjSkidYYuZpYwqolQzCmWNzZ YGQg== X-Gm-Message-State: AOAM533hKm0NCX5MqINF33ShOMp74w+2K4Bsi4USpd+gIVd1P4OBSMWs h1vvAfh9o8v2r523YogSa4WfkrhUm2U5t1dL X-Google-Smtp-Source: ABdhPJykZRk3fnAwVZzi6B5/n7hAE35vzdTisKQtKNXo61OdMdbRiLl2C1NFxQeMDC70ZuwM9nd7Mw== X-Received: by 2002:a7b:c2f0:: with SMTP id e16mr8279270wmk.144.1628729659608; Wed, 11 Aug 2021 17:54:19 -0700 (PDT) Received: from smtpclient.apple (trinity-students-nat.trin.cam.ac.uk. [131.111.193.104]) by smtp.gmail.com with ESMTPSA id p14sm7612124wmi.42.2021.08.11.17.54.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Aug 2021 17:54:19 -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 01:54:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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:52, Palmer Dabbelt wrote: > On Wed, 11 Aug 2021 16:32:38 PDT (-0700), jrtc27@jrtc27.com wrote: >> 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: >>>>> 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. >>=20 >> 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. >>=20 >> 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. >=20 > OK, no problem. Next time just please make it clear when you guys = send something out for review that all discussion here is irrelevant, = because it'll save us the time. That=E2=80=99s an unfair characterisation and, whilst I appreciate that = Jim=E2=80=99s reply was antagonistic in places, please do not take it = out on me by using that kind of tone; I=E2=80=99ve tried to address all = your comments and concerns with technical justifications. Were there to = be actual problems with the implementation we would of course take that = feedback; that is one of the reasons why we don=E2=80=99t merge a = consequential specification change until people have actually = implemented it. In this case AArch64 has already gone this route two = years ago and lived to tell the tale without obvious issues so in this = specific case there=E2=80=99s unlikely to be a problem that would result = in us not adopting the proposal, but it=E2=80=99s always possible = we=E2=80=99ve missed something. My point was =E2=80=9Cthis is the = specification we (the psABI chairs, plus representatives from both the = GNU and LLVM world) will be going with unless anyone has a good reason = why it is a bad idea=E2=80=9D. However, there is a small element of truth to your comment. Discussion = here isn=E2=80=99t irrelevant, but it=E2=80=99s not the primary place = for ABI specification discussions. Because the RISC-V psABI tries to = show no preferential treatment to a specific OS or toolchain (or, in the = case of Linux, libc implementation) and seek a specification that works = for all, the primary place for discussions is not a GNU-specific or = Linux-specific mailing list but the psABI repository, mailing list and = meetings (for which there publicly-available minutes), and those who = want to have more of an input into it should contribute to the = discussions there (anyone is free to offer feedback on psABI = issues/PRs). When necessary we do try to reach out to the mailing lists = for the specific communities involved (e.g. on the compiler front both = GCC/binutils and LLVM have their own regular RISC-V sync-up calls where = issues can be brought up and discussed with the outcome reported back to = the psABI task group), and feedback on proof-of-concept patches that = relate to the specification rather than the implementation will be taken = into account, but to avoid fragmentation the ultimate sources of = rationale and places for discussion are in general those common central = locations. I=E2=80=99m also not sure why you=E2=80=99re acting so surprised about = this addition to the psABI; you yourself reviewed the pull request in = question back in May and, as far as I can tell, it had already adopted = the STO_RISCV_VARIANT_CC nomenclature, and was only using vector = registers as an example of a non-standard calling convention, by that = point. Since your conditional approval the wording has been overhauled, = in part to address your feedback on wording that was the condition for = your approval, but nothing that actually changes things as far as = implementations are concerned. And to be clear, I had no part in the authorship or publishing of this = patch, nor do I have any kind of affiliation with SiFive. What SiFive, = or its employees, do is entirely up to them and completely independent = of myself as co-chair of the psABI specification task group. All I ask = is that patches exist; whether they=E2=80=99re proposed as RFC/PoC or = not is none of my business beyond making sure that implementations = don=E2=80=99t officially adopt new ABI features before they are made = official (or at least the kind that matter for compatibility) as that = causes as much of a headache for me as it does you. > IIUC the ABI patch still isn't merged, which is what makes it actually = official. Of course. If in light of the technical explanations from Jim and myself = you still feel there are reasons why this should not be adopted then = please do express them, but otherwise I expect it will be merged = shortly. > I'll take this when it lands. Sure; I=E2=80=99d do the same in your shoes too. Jess >> Jess >>=20 >>>> 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