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=-2.9 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 7B0581F953 for ; Thu, 2 Dec 2021 20:22:06 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5C78C385C41B for ; Thu, 2 Dec 2021 20:22:05 +0000 (GMT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id A6FAC3858003 for ; Thu, 2 Dec 2021 20:21:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A6FAC3858003 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-pg1-x529.google.com with SMTP id m15so840527pgu.11 for ; Thu, 02 Dec 2021 12:21:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=date:subject:in-reply-to:cc:from:to:message-id; bh=NJmtxOioFydKzF/hV8+dJDEMfGmMczZ9h52b/k2liYE=; b=hXqWd2DjLHqW4OBZLT1PRYSkq8CKqXq1nAKiqirDYNBJSzGAnc7eZiQUXBVRPTD3/B DaA1NnIL3XCf4QlsQXeuzE355h5tkMM3nf/rvqfNqi2GlREST9s9c7L9JcW5qyaXNjo2 DOE/RRsBs9/wSWjjVJqMNEL5W2aDAaGAGQPNTduTvscmybBfCHY1JFCYpuC31Lih56/r QqcmnEvFRlv0cy6cChil+/axaDmEX6qs4BLlRETS97KWNzlIoeueo2e7xpE5Pkcr2+on 2yIjm77sBVscrKAE9dNQ8qGsqrCWXOeJMtfMpr7HcXwA0epXt3zKBdgDbcCjIicmUMd2 Z8tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id; bh=NJmtxOioFydKzF/hV8+dJDEMfGmMczZ9h52b/k2liYE=; b=PDYtv0SCMi9rVbjuLjw9Qxnp1OoMDkV0+pmvJwOgChh/dFlHcyQ67KL5YOmSWRp2in QR9urMDyDus9/P6XpxaCuBxyHTWdEeR6yBamM8TyMLR18qehcEFb8HDwvVmN+qplaMmu T8XcnXs+3jfRdKwa5T9KDOdXa2qRQapjzP73cfDX+plzCSS1B/MTh4/n0jEcnQfoT6SX uS4GAM4wJ04Z/Ta3YxqEpdW6TIaH70PJwVrXtsZ08DDAX5vvSvZePwJySeld4W7Uf/kX kGrLnlKbfVRx1vvRIVWfz+KHHvg+WlLa19R8aXExCUq0GLlBVUET9IyhhQjfrmSX3yqP H49A== X-Gm-Message-State: AOAM5329YEzIzOTxNagpGq5mlr0Mzuaj59trFch/IHVjmumxDHkBkHrj NZDugkhlz349dPQ6Q0euyAR0xw== X-Google-Smtp-Source: ABdhPJxI0LvZMA1Ul4T88w0eIvUJuXnPSIlUZNUvE7OTgS4+t6tc/MU3E/KAhwtayKWTj/UUKI9fAw== X-Received: by 2002:a65:40c3:: with SMTP id u3mr1138299pgp.160.1638476512554; Thu, 02 Dec 2021 12:21:52 -0800 (PST) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id i67sm596450pfg.189.2021.12.02.12.21.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Dec 2021 12:21:51 -0800 (PST) Date: Thu, 02 Dec 2021 12:21:51 -0800 (PST) X-Google-Original-Date: Thu, 02 Dec 2021 12:18:52 PST (-0800) Subject: Re: [PATCH] riscv: Resolve symbols directly for symbols with STO_RISCV_VARIANT_CC. In-Reply-To: From: Palmer Dabbelt To: Jim Wilson Message-ID: 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: libc-alpha@sourceware.org, jrtc27@jrtc27.com, Andrew Waterman , kito.cheng@sifive.com Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" [Changing to Jim's new address] On Mon, 25 Oct 2021 14:08:26 PDT (-0700), jimw@sifive.com wrote: > On Wed, Aug 11, 2021 at 4:52 PM Palmer Dabbelt wrote: > >> IIUC the ABI patch still isn't merged, which is what makes it actually >> official. I'll take this when it lands. >> > > Just following up, the psABI patch was merged in > https://github.com/riscv/riscv-elf-psabi-doc/pull/190 > and the psABI has gone into public review for the first official release. > So we would like this patch from Kai merged in. > https://sourceware.org/pipermail/libc-alpha/2021-August/129931.html > in case you lost track of the original message on this thread. Sorry this took a while, there's a lot of context here and I figured it'd be good to run through that as the issue in play has a pretty roundabout effect on this patch. This is a little long, but I promise it gets there at the end: We had a long-term outstanding issue on the psABI spec , which essentially boils down to glibc relying on lazily bound functions to follow the standard calling convention. The actual issue isn't specific to vector registers, we're relying on this for X and F registers too, but AFAIK there's no users of non-standard X/F register calling conventions for lazily bound functions so we haven't had any user-visible bugs yet. This all becomes a lot more important with the recent addition of V registers, which are both more expensive to save and all clobbered by the standard ABI. In order to address the desire for non-standard calling conventions driven by the standard V register map, the following text was added to the psABI spec: Run-time linkers that use lazy binding must preserve all argument registers used in the standard calling convention for the ABI in use. Any functions that use additional argument registers must be annotated with STO_RISCV_VARIANT_CC, as defined in Section 8.4. As a result of adding that language the bug in question about the lazily bound functions was resolved. We're relying on lazily bound functions following a lot more of the standard calling convention than that in glibc (sp, and ra for example; along with all the temporaries). The text in question doesn't directly address any of those assumptions, and given that there's historically been user-visible breakages around these ambiguities I think it's prudent to be more explicit about what the glibc ABI is here. As far as I can see, there are really three ways to go about this: * We can just define the defacto divergence that glibc has always had from the psABI in this area. That's the smallest change, as IMO that's as simple as diff --git a/manual/platform.texi b/manual/platform.texi index d5fdc5bd05..9153408966 100644 --- a/manual/platform.texi +++ b/manual/platform.texi @@ -121,6 +121,9 @@ when it is not allowed, the priority is set to medium. @node RISC-V @appendixsec RISC-V-specific Facilities +Functions that are lazily bound must be compatible with the standard calling +convention. + Cache management facilities specific to RISC-V systems that implement the Linux ABI are declared in @file{sys/cachectl.h}. to start, adding something like "unless those functions are annotated with STO_RISCV_VARIANT_CC" after merging something very similar to the patch in question (I haven't looked closely at the code, but it seems pretty-straight-forward). * We can do our best to allow for the additional functions this new text implicitly allows. I don't see anything we can do about RA and SP, but we could save the registers we clobber in _dl_runtime_resolve (including the F registers on non-F libraries running on F systems, which will be a headache). We'd still need some additional glibc-specific ABI for the bits of the standard calling convention we can't otherwise handle, but IMO those are pedantic enough that we could just disallow them entirely. * We can just stop doing any sort of lazy binding. That would allow us to any relying on any unspecified behavior. The first option is preferable from my end, as the second option would require a lot of complexity (both specification and implementation) as well as come with a likely performance hit.