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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.0 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (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 54D4B1F8C6 for ; Wed, 11 Aug 2021 23:01:05 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4063A3992028 for ; Wed, 11 Aug 2021 23:01:04 +0000 (GMT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 99C82384F030 for ; Wed, 11 Aug 2021 23:00:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 99C82384F030 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-lj1-x22c.google.com with SMTP id n6so7309749ljp.9 for ; Wed, 11 Aug 2021 16:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cUCZWRbKmQy2DVTGMHTwxNlhBlTVd1FVj9+CJfjQIHY=; b=nFMRjeq3U/QJMQzh7XsCTfsg/w6zQQFm/1ElhOSpmlwtQzsOlXGRq+ZQ8HTtF7nGPZ /nhG/eiKZaFLQRCY3lYYbsnVpWimOOfjxZZoWzvmtCBRUzSOffJbXZqFCJOfYVcizl4j MNNMIkYYS6hmA5JDNd+Lb1Zqjm1fX9Nl7oGnXWsw8o2IkZc/SwWFWf0pVWABza3EORR1 ZopypxUMEYtTw9prd6UXQTNhDIv3ZPtKXYJRkSI60qyCygvc+UUlC/n+4u22JJ0V6luS Iu6bK4jYYXQSMSkK8bjaCHOGdNwXZ8LmmJtmBwdvYV7zo8wi+ZNMyQ37dyYtfuywycsF Fp/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cUCZWRbKmQy2DVTGMHTwxNlhBlTVd1FVj9+CJfjQIHY=; b=SBH9E9mFZbsAQZUE8CvULO4I5xt4KjVY9ijPEdacG+xC5QLuP9IRsDOR9vKogKOHTn VEBBKxZEWaPL+0L0LdowR6Cj5k2jIJae/4McMV6ZtNy69PgxooUCrcjyRUwwoQy+tEqc K5w3Vlk9YdBrxisG5D+ktXf92pbPCJmeIQHNEZjqVOiP4+GvS54fiUi5wlfb4weTcO8H dd/yBt48A9ApoDnDKJVy8Sk+uBWWevn0quWl+fYQzrvuVoWVxpXu7GuANOjNq/FKZ5EQ 4aYcL5+ASSiL3Yu/J72qye0+d3uZjhylnQS3an1BkUYq5ma1Npslw1KS7EJK+s7Ap+ya D71A== X-Gm-Message-State: AOAM5339PuqbHmAYkA8GljDS4odfqTW3RVMI+59q4f0UCKTMRp34YzX0 v31TYv69grmQluNmXrCwUUKWRfcWkEenE5in73LFpdO6Dw8= X-Google-Smtp-Source: ABdhPJzhofBcVd6FWjFBOYy0kxU9GhWGV9d4iBxIRcjMVOgVZus5W+GqgeNkftXnW0v9FTfkg2/3cQNpAhsTM1xlgjE= X-Received: by 2002:a05:651c:b28:: with SMTP id b40mr729500ljr.504.1628722842325; Wed, 11 Aug 2021 16:00:42 -0700 (PDT) MIME-Version: 1.0 References: <1628480827-366232-1-git-send-email-kai.wang@sifive.com> In-Reply-To: From: Jim Wilson Date: Wed, 11 Aug 2021 16:00:31 -0700 Message-ID: Subject: Re: [PATCH] riscv: Resolve symbols directly for symbols with STO_RISCV_VARIANT_CC. To: Palmer Dabbelt Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: James Clarke , GNU C Library , Andrew Waterman , Kito Cheng Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" 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. 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