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.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,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 C3A8A1F953 for ; Thu, 2 Dec 2021 21:06:48 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B8D113857C4E for ; Thu, 2 Dec 2021 21:06:47 +0000 (GMT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id E7A9C3858003 for ; Thu, 2 Dec 2021 21:06:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E7A9C3858003 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-wr1-x429.google.com with SMTP id u1so1315338wru.13 for ; Thu, 02 Dec 2021 13:06:35 -0800 (PST) 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=NeED4voIwqG41ZqvY0f7bS1l1xHzZYxmHxIqY8tOLHU=; b=Ih3dvgQ7UAGrtbHVDXUCSfd1HPqH1lMlzpPHZQmcT91cXNNyHgj/L8mI3C/Qh1vKcs A3iqad/OTa1AZnWhXx5b8LNTSmOG2HqeG3AdfW2KayWotp2JKY42PPuVve8fq6Ha1urB fmH6Qb7ER5O9iaIXIEriFUV6gl1AeAuhJUfVft7C8fzTUMem7wUQnMk2KtTzPlajq6zB k/OI5UUcTIzaR4YDhYeaJJajKwGh+EZtofZitR/YgZAneJpH2pyodk4vibJbHoQbUcSe z6nKDu3B3V68kz18MP8RWPT1g4tjjXkDYvwtKmny+26Zdq63414A2ku/x3T6hi+bzdiQ hNmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NeED4voIwqG41ZqvY0f7bS1l1xHzZYxmHxIqY8tOLHU=; b=t+tchLhLzN/xHWOqFF6/aUfr4cpQNDAB0obQObw9YEt+tiVwaWRvx8ykr8WVHjcfLt kR1aJMaKTRTJdV4ws0bqGQecufJ2IDYEF4ANN4dZMR3WWbfMhlwNBZGA0UDPi+tiDwmu yGL8Va7N9+7VB1zYRNu8BorRZ5DBghNTqp/3Gy2lwXrCh3ZVUY44GLrT8IgDTreYIewk zRAx9i0Sew9ShLXxe3h441QYJEl1E5HEDCZ12Y7GuiyIO0xEtLG8m3bxwIVM47x1E1Vy xRou6vCk+yKe7CJaAeKyOoAuKhwOLl+hbZkd7LPwpn2ShqkLGSDgnlYBTsI+Fc5ms7FE JNaQ== X-Gm-Message-State: AOAM531MBmdkqV3OVNUT2Bz6A7Q3y8BOvQxAsfDjawzczmjB3xZtXEWY GWFJt3a0V14xZKiNTswedyjDPg== X-Google-Smtp-Source: ABdhPJziYBcvV8+dDuo9sC1cTV0zgCu6vtY4vX6UGZ/LHhUEL6OXNaiUZozvby2EIzH4XPfJOKBSZg== X-Received: by 2002:a5d:584c:: with SMTP id i12mr16778711wrf.95.1638479194817; Thu, 02 Dec 2021 13:06:34 -0800 (PST) Received: from smtpclient.apple (global-5-141.nat-2.net.cam.ac.uk. [131.111.5.141]) by smtp.gmail.com with ESMTPSA id f18sm806045wre.7.2021.12.02.13.06.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Dec 2021 13:06:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: [PATCH] riscv: Resolve symbols directly for symbols with STO_RISCV_VARIANT_CC. From: Jessica Clarke In-Reply-To: Date: Thu, 2 Dec 2021 21:06:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <60359D93-BA59-486D-BCD5-8EB582700FA9@jrtc27.com> References: To: Palmer Dabbelt X-Mailer: Apple Mail (2.3654.120.0.1.13) 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 2 Dec 2021, at 20:21, Palmer Dabbelt wrote: >=20 > [Changing to Jim's new address] >=20 > 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: >>=20 >>> IIUC the ABI patch still isn't merged, which is what makes it = actually >>> official. I'll take this when it lands. >>>=20 >>=20 >> 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. >=20 > Sorry this took a while, there's a lot of context here and I figured=20= > it'd be good to run through that as the issue in play has a pretty=20 > roundabout effect on this patch. This is a little long, but I promise=20= > it gets there at the end: >=20 > 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. >=20 > In order to address the desire for non-standard calling conventions=20 > driven by the standard V register map, the following text was added to=20= > the psABI spec: >=20 > Run-time linkers that use lazy binding must preserve all argument=20= > registers used in the standard calling convention for the ABI in=20 > use. Any functions that use additional argument registers must be=20= > annotated with STO_RISCV_VARIANT_CC, as defined in Section 8.4. >=20 > As a result of adding that language the bug in question about the = lazily=20 > bound functions was resolved. We're relying on lazily bound functions=20= > following a lot more of the standard calling convention than that in=20= > glibc (sp, and ra for example; along with all the temporaries). The=20= > text in question doesn't directly address any of those assumptions, = and=20 > given that there's historically been user-visible breakages around = these=20 > ambiguities I think it's prudent to be more explicit about what the=20 > glibc ABI is here. >=20 > As far as I can see, there are really three ways to go about this: >=20 > * We can just define the defacto divergence that glibc has always had=20= > from the psABI in this area. That's the smallest change, as IMO=20 > that's as simple as >=20 > 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 >=20 > +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}. >=20 > to start, adding something like "unless those functions are=20 > annotated with STO_RISCV_VARIANT_CC" after merging something very=20 > similar to the patch in question (I haven't looked closely at the=20 > code, but it seems pretty-straight-forward). > * We can do our best to allow for the additional functions this new = text=20 > implicitly allows. I don't see anything we can do about RA and SP,=20= > but we could save the registers we clobber in _dl_runtime_resolve=20 > (including the F registers on non-F libraries running on F systems,=20= > which will be a headache). We'd still need some additional=20 > glibc-specific ABI for the bits of the standard calling convention we=20= > can't otherwise handle, but IMO those are pedantic enough that we=20 > 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. >=20 > The first option is preferable from my end, as the second option would=20= > require a lot of complexity (both specification and implementation) as=20= > well as come with a likely performance hit. Thanks for the detailed review of this corner of the spec, it=E2=80=99s especially valuable at the moment whilst we=E2=80=99re trying to reach a ratified version (though all the confusing/inconsistent/ill-defined terminology is even less appropriate here, at the end of the day the ABI is what the toolchains and runtimes say it is so it=E2=80=99s really = just about getting the necessary rubber stamps to get the next label and reviewing the document style and exact language used...). The intent of the spec is not to make repurposing just ra/sp/gp/tp as anything other than their ABI-defined meanings (per table 1 of riscv-cc and, in the case of the stack pointer, the alignment required by the integer calling convention) legal unless you use STO_RISCV_VARIANT_CC, so the glibc requirement, which is also true of FreeBSD for exactly the same reasons, is intended to be what is specified. Upon re-reading what was written I can see that requirement was lost or forgotten, so I=E2=80=99= ll look at tightening it up, probably changing Any functions that use additional argument registers ... to Any functions that use registers in a way that is incompatible with the register convention of the ABI in use ... I also note we currently only talk about the run-time linker preserving argument registers, and say nothing about preserved registers, nor the return address. I=E2=80=99m not sure quite why we do the former (maybe = I=E2=80=99ve just forgotten a past conversation), I feel like that=E2=80=99s implied = by lazy binding being an implementation optimisation that must not break the calling convention, but if we want to keep that language then it should probably be changed to: Run-time linkers that use lazy binding must only clobber registers defined as temporary registers for the ABI in use. Does that all sound sensible, and sufficient, to you? Jess